NAND + SSHD Layout

Community Support for the machines running the game
User avatar
thebs
Master
Master
Posts: 732
Joined: Sat Apr 16, 2016 6:49 pm
CMDR: thebs
CMDR_Platform: None Specified
Contact:

NAND + SSHD Layout

Postby thebs » Fri Jan 20, 2017 10:31 pm

Moved from: viewtopic.php?f=9&t=6939#p78889

Now, on system layout ...

When I self-assemble/self-install, I usually partition as follows (using a Linux LiveUSB stick first) ...



NAND device (usually 240-256GB)

MBR -- Master Boot Record (MBR) Partition Table aka MSDOS Disk Label

Code: Select all

 # |  ALLOCATION   (  SIZE ) | TYP ( DETAILS ) | Windows or other Purpose
---+-------------------------+-----------------+-----------------------------------------
   |   0 -   1 MiB (  1 MiB) | --- (MBR)       | Master Boot Record (plus hidden sectors)
 1 |   1 - 512 MiB (511 MiB) | 07h (NTFS)      | Windows %SYSTEMDRIVE% (BOOTMGR)
   | 512 -1024 MiB (512 MiB) | --- unallocated | could be used as 83h Ext4 Linux /boot
 2 |   1 - 128 GiB (127 GiB) | 07h (NTFS)      | Windows %BOOTDRIVE% (C:\Windows)
   | 128 +     GiB           | --- unallocated | reserved NAND over-commit, 8Eh LVM Linux

GPT -- GUID Partition Table (GPT) Disk Label

Code: Select all

 # |  ALLOCATION   (  SIZE ) | TYPE  ( DETAILS ) | Windows or Other Purpose
---+-------------------------+-------------------+-----------------------------------------
   |   0 -   1 MiB (  1 MiB) | ----- (GPT)       | GUID Partition Table structures
 1 |   1 - 384 MiB (383 MiB) | EF00h (FAT32 ESP) | %SYSTEMDRIVE% EFI System Partition (ESP)
 2 | 384 - 512 MiB (128 MiB) | 0C01h (msftres)   | Mandatory 'Microsoft Reserved Partition'
   | 512 -1024 MiB (512 MiB) | ----- unallocated | could be used as 8300h Ext4 Linux /boot
 3 |   1 - 128 GiB (127 GiB) | 0700h (NTFS)      | Windows %BOOTDRIVE% (C:)
   | 128 +     GiB           | ----- unallocated | reserved NAND over-commit, 8E00h LVM Linux


For GPT, Microsoft requires a 128MiB (16GiB if the disk is <32GiB) Type 0C01h 'Microsoft Reserved Partition'. This is where Microsoft can store non-filesystem data for boot and 'safely reading' NTFS file systems the same system didn't create (long story, long history of NT instances corrupting NTFS file systems it didn't create). Previously Microsoft used to put these in 'hidden sectors' at the end of the disk or in the MBR, which was always problematic. Microsoft recommends the partition be immediately after the %SYSTEMDRIVE% but before the %BOOTDRIVE%.

NOTE: Yes, %SYSTEMDRIVE% (formerly NT3-5 NTLDR, now NT6 BOOTMGR) and %BOOTDRIVE% (C:\Windows) seem backwards. The "boot files" are on the %SYSTEMDRIVE% and the "system files" are on the %BOOTDRIVE%. That's a legacy hold-over from the original NT3.1 nomenclature still yet addressed.

Now why do I do this?

- Never use the first 0-1MiB (1MiB = 2,048 x 512B logical sectors or 256 x 4KiB logical sectors) -- the MBR should have all 1MiB (Microsoft stupidly writes a lot in here, along with Linux GRUB needing a lot), and GPT requires at least 33 sectors (16.5KiB) to store the metadata for minimum of 128 partitions

- Separate 'System' Partition (%SYSTEMDRIVE%) results in no issues with large disks or problematic setups -- required for uEFI (ESP). With FAT32, if the logical sector size is 4KiB (all disks are physically 4KiB+, but often logically 512B -- NAND is at last 32KiB physically), so that is a minimum size of 260MiB (I round up to 384MiB for GPT, 512MiB for MBR). In the near future systems will have logical 4KiB, so 100-200MiB %SYSTEMDRIVE% will not work with FAT32, and FAT16 is not recommended for a fixed disk ESP.

- I leave a 512MiB (0.5GiB) "hole" in the 2nd half of the first 1GiB for a future Linux /boot partition

- I always align on 1GiB partitions, years of partitioning just makes is more simple

- A smaller %BOOTDRIVE% (C: ... where C:\Windows is at) means it's much easier to recover from issues on the %BOOTDRIVE% as well as backup/restore wholesale.

- Also, starting with only a 127GiB C: drive means lots of over-commit ... I can always expand it if needed ... but I get a lot of NAND over-commit (much longer lifespan)

- I also create a C:\SteamSSD folder for games that need the read performance of NAND (e.g., Fallout 4)

More tips and reasons why I do this ...

- Although C:\Windows is hard on NAND, Windows Update is 100x faster on NAND. Why? Microsoft writes 200:1 during updates, which is why Windows Update is so slow on platters. E.g,. if you update 1GiB of Windows/Office, it will write 200GiB (0.2TiB) to your NAND devices. Yes, that wears it out faster, but it also means 1GiB of updates take 10-30 minutes ... instead of 5+ hours.

- Using a small 127GiB C: drive means there is a lot of over-commit with just a 240-256GB drive. It also means you can backup your C: drive rather quickly, even dd (for those of us who are Linux wennies) and replace it at any time by just dd'ing it back (although you'll need to preserve the GPT Universally Unique IDs, UUIDs, on your partition if you are using GPT and native uEFI firmware boot -- Windows expects them to match).

- I actually have a 383GiB C: drive, on a 1TB NAND device, in this system -- which gives me plenty of space for C:\SteamSSD



SSHD device(s) (2TB+ -- including multiple drives in RAID-1, 10, 5 or 6)

GPT -- GUID Partition Table (GPT) Disk Label

Code: Select all

 # |  ALLOCATION   (  SIZE ) | TYPE  ( DETAILS ) | Windows or Other Purpose
---+-------------------------+-------------------+-----------------------------------------
   |   0 -   1 MiB (  1 MiB) | ----- (GPT)       | GUID Partition Table structures
 1 |   1 - 384 MiB (383 MiB) | EF00h (FAT32 ESP) | %SYSTEMDRIVE% EFI System Partition (ESP)
 2 | 384 - 512 MiB (128 MiB) | 0C01h (msftres)   | Mandatory 'Microsoft Reserved Partition'
   | 512 -1024 MiB (512 MiB) | ----- unallocated | could be used as 8300h Ext4 Linux /boot
 3 |   1 -xxxx GiB (  y TiB) | 0700h (NTFS)      | Windows Data/Games Partition (D:)
   | aaaa-bbbb GiB (  c TiB) | ----- unallocated | optional 8E00h LVM (swap, /tmp, /var)


- I always create my non-C: drives as GPT, even if the system and the first drive, with C:, is boots using Compatibility Support Module (CSM) aka "Legacy" PC BIOS Int13h Disk Services.

- Same 1GiB first reservation as the NAND, a minor cost to reserve the areas (like the ESP)

- Again, I always round to the nearest GiB ... I do not use the last bits of the disk, but cut it off. E.g., if the drive is 2TB = 1.82TiB = 1,862.6GiB, I round down to 1,862GiB, and I might even do 1,860GiB because I like multiples of 4.

- If you have Linux, do not put swap, /tmp or /var on NAND, but platter. Although Linux will wear out a NAND device far less than Windows (let alone APT/YUM 2:1 commit v. Windows Update 200:1 commit), a major reason advantage is the strict separation of temporary and variable files in Linux that have a high rate of change, whereas Windows puts crap all over the place (although TMP=D:\TMP and TEMP=D:\TEMP helps!). If you don't have a platter drive, and only NAND, for Linux ... use no swap, setup tmpfs for /tmp and /var/tmp and, sparringly, use /var on NAND.


NOTE: There was an issue with the Windows 10 Anniversary Update where Microsoft thought NAND C: + SSHD D: was just a 'niche' thing no one uses. But that's been largely fixed as of late last fall / early winter.
Image
CMDR TheBS - Yet Another Middle Aged American (YAMAA) and Extremely Casual Gamer often confused for a Total Noob

Return to “Hardware and Technical”

Who is online

Users browsing this forum: No registered users and 4 guests

i