Noob question: why seperate partition for EmuMMC?

From what I understood, Emummc creates a copy of the 32gb onboard memory of the switch and makes the switch on cfw think that is its built in memory.

Then the rest of your SD card becomes your installed SD card. The switch will notice the two and act accordingly.

 

You don’t want windows to recognize the EmuMMC partition. The 30gig space is utilized as a second nand (a 1:1 copy of your sysnand) so you are correct it’s like having two switches. One for CFW/offline/EmuMMC and one for stock/online/systemMMC.

 

It would be nice to have Windows recognize it as something other than unpartitioned space, at least. The way Windows displays partitions it doesn't recognize (such as Linux or Mac partitions) is by displaying it as occupied in Disk Management and simply not mapping a drive letter. By having it show as unpartitioned space you run the risk of accidentally formatting it if whatever formatting program you use reclaims unpartitioned space by default. And none of them advertise if they do or not, so it's really a guessing game unless you already know if that particular formatting program will or won't do it.

I guess this might cause issues with the Switch when it actually tries to mount the SD card, if it's hardcoded to only mount the first partition on the card and isn't intelligent enough to try the next one if the first one fails. No idea if that's the case or not, testing is needed.
Fun fact: All windows versions up to and including Windows 7 (and possibly 8/8.1 - not used it much) would only mount the first partition on a SD card or flash drive. There was literally no way you could mount the other partitions, besides using hacky drivers to fool Windows into thinking the card or flash drive is an actual hard drive. Even so it was still intelligent enough to ignore partitions that it's not able to recognize the format of anyway, and mount the first recognizable partition. In Windows 10 this is thankfully no longer a limitation (the limitation made no sense to begin with)

 

The switch will only mount the first numbered partition. You may use sfdisk to change the partition number of the one you'd like to store stuff on

— Posts automatically merged - Please don't double post! —

other than this, order doesn't matter

 

I see. And by default with Atmosphere the emuNAND is placed at the end of the card anyway isn't it? So it wouldn't matter for most people, only those who moved from SX OS or are dual booting both and kept their SX emuNAND.
Putting it at the end of the card does make more sense. Also makes it easy(ish) for someone to delete their emuNAND and reclaim the space by expanding the first partition without formatting their card.

Note: I refuse to call it "emuMMC". The "emuNAND" terminology was just fine and changing it will only serve to confuse people into thinking that they are somehow two different things. Both terms are equally accurate here, but there was really no point in changing it in the first place. If they just wanted to be more descriptive/correct then it should logically be called "redMMC". This new terminology seems like nothing more than a way for the ReSwitched team to feel special when they get to invent new terms. </rant>

 

I prefer putting it at the beginning of the microSD card. If I upgrade to a larger card in the future I can just dd it to the other card, and afterwards expand the FAT32 partition to the end of the new card.

With it at the end of the card, moving to a bigger microSD card is a bit trickier, although it still can be done.

 

True, though if the emuNAND was actually recognized as a partition instead of being "unpartitioned", making images of it or cloning it to a new drive would be easy. Instead, we need tools made specifically for the Switch to do such things if we don't want to image the entire card, or fuck around in a hex editor to extract just the emuNAND out of it.

Actually, the first version of Xecuter's emuNAND solution did store the emuNAND as files inside the real NAND. There are several drawbacks to this.

First of all it will be slower and more prone to corruption, as there is an additional file system layer inside the existing file system, making reading and writing less straightforward. It doesn't have a huge impact if programmed correctly, so this is mostly a non issue.

Secondly, and more importantly, this effectively halves the space on your NAND as half of it is used for your sysNAND and half of it is used for your emuNAND. Not a huge deal if you have a big SD card and store all your games on it, but keep in mind save data is always stored on NAND and this could add up to quite a bit over time especially on a hacked console with lots of games, or if that console is used by multiple people with separate accounts.

And thirdly, it is really easy for Nintendo to detect these files stored on the NAND. Something they could almost as easily do with emuNAND on SD, but you could simply eject the SD card before you boot into OFW and there would be no way to tell that your console has ever had an emuNAND on it. Can't really do that if it's all stored in your internal NAND...

And keeping emuNAND on a separate partition is just in general cleaner. I for one like keeping all my CFW stuff fully isolated from my legit stuff. Might not matter to some people though.

And yes, emuNAND does need to take up some amount of space. At minimum, however much space the other partitions besides USER take up, and some amount of space for USER itself for save data unless you want USER to be shared between sysNAND and emuNAND (which would be a bad idea and likely result in bans eventually)

That's because the entire premise is to have a separate set of firmware and system/user data so that you can update one without affecting the other, or keep your sysNAND clean from the log files and installed nsps you have in CFW, so you can go online with your legit games.
It doesn't need to be on the SD, but it needs to be somewhere Where it's placed doesn't matter as to how much space it takes up that you're not able to use for games. Putting it on the SD card just makes more sense.

However, you can install games to NAND while in emuNAND which allows you to use most of that ~30GB that the emuNAND takes up to store games on. The other partitions are only like 3GB in total, so there's a whole ~27GB there for you to use for installed nsps and save games. So you're not giving up as much space as it might seem.

 

hekate creates a valid partition but uses a foreign identifier that windows doesn't recognize, use real partitioning tools like fdisk and it shows up right away

 

So does Windows actually recognize the identifier of EXT2/3/4 partitions? I wouldn't think so based on how it just shows it as a generic partition, but you may be right.

 

yup

even if hekate DID delete the partition it wouldn't be a big deal at all since nothing other than malware will arbitrarily write to your disks

 

True, but if you formatted your SD card and it ended up "removing" the emuNAND partition, even though the data is still there, it might be overwritten when you load up the card with files again not realizing what has happened.

 

Formatting the sdcard doesn't involve repartitioning (unless the entire sd is unallocated) and will leave the empty area as it was

 

I know that at least in SDFormatter there is an option for "format size adjustment" that will do this, though it's not enabled by default. I can't be sure that other formatters won't have this enabled by default though. I know the Windows formatter will never do anything to the "unpartitioned" space, but can you really be sure that no formatter will? MiniTool and guiformat I have little experience with and I wouldn't claim to know how they behave in cases such as this. So I would be wary. Formatting a drive always involves repartitioning to some degree, as the partition table is rewritten to be whatever file system you selected.

 

The reason i told the OP the they don't want windows to recognize the second partitions was because of an issue that i had ran into. This was where both partitions were set as primary and windows 10 (in my case) would see both with second partition be blank. it would work just fine for Emummc until i removed the sd and put it back in the PC and then the second partition would no longer work and hekate couldn't mount it. Setting the partition as logical fixed it to where i could reinsert in PC and no issues would arise unless an accidental format occurs. This is more than likely due to the program i used to make the partition but it works so I'm leaving it as is. I didn't want the OP to go reformatting for no reason, just because they couldn't see the partition from windows.

 

Huh. You have three partitions on your SD (counting emuMMC)?
Or if the second partition is the emuMMC, how did you get Windows to recognize it?

 

Nope. Second is EmuMMC.
Windows 10 for me would recognize it when both partitions were set as primary. But like i stated, windows would do something to corrupt the EmuMMC and would no longer boot EmuMMC if i reinserted the SD into the PC.

 

The answers to both questions can't be nope.

 

i edited my previous post. Your too fast. LOL

 

Okay, then what do you mean by the program you used to make the partition? Did you not just make the emuNAND through the Switch itself?