# Recommendation for GPT alignment of USB-(Flash)-Memsticks?



## obsigna (May 6, 2014)

I tried to search the web for this question, but except that alignment is important for flash memory, I got no exact information about what value is generally recommended.

Does a general recommendation exist?
What would be the ideal -a parameter for the `gpart add` command?

Let me ask another perhaps stupid question. May I assume that a common commercial USB memstick comes with a unique blocksize, or in other words may it be that there is a positive or negative offset, e.g. at the start of the stick?


----------



## wblock@ (May 6, 2014)

*Re: Recommendation for GPT alignment of USB-(Flash)-Memstick*

The empirical way is to test it.  Short of that, I would use 4K alignment and put the first filesystem partition at 1M, the same as on a disk or SSD.  If MBR partitioning is required, use fdisk(8) to create the slices, because gpart(8) rounds slice locations to CHS values, almost never aligned with a sector multiple.


----------



## obsigna (May 6, 2014)

*Re: Recommendation for GPT alignment of USB-(Flash)-Memstick*

Warren, many thanks for your quick reply.

What does CHS values mean?

On FreeBSD, I do everything with GPT disks. However in this special case I want to prepare one FAT32-Pendrive for data exchange between various OS. In a first pass I took your parameters 4K alignment starting at 1M using gpart(8), because I am much more comfortable with that compared to fdisk(8).

`# gpart create -s MBR /dev/da0`
`# gpart add -a 4k -b 1M -t fat32 /dev/da0`
`# newfs_msdos -F 32 /dev/da0s1`

The pendrive works, i.e. I can put data on it on FreeBSD and read it out using Mac OS X, and on Windows 7, however:

`# gpart show`

```
=>     63  7831489  da0  MBR  (3.7G)
       63     2016       - free -  (1.0M)
     2079  7829451    1  fat32  (3.7G)
  7831530       22       - free -  (11K)
```
This does not look quite aligned. From the command sequence I would have expected that the first partition starts at 2048. What make me totally suspicious is the remaining block size of 11K, which has no divisor above 1024, for this reason my question about non-unique block sizes. Am I right, that this formatting is completely unaligned? So, do I really need fdisk(8) for this.

Anyway, now I try the same with GPT formatting for freebsd-ufs on the same pendrive:

`# gpart destroy -F /dev/da0`
`# gpart add -a 4k -b 1M -t freebsd-ufs /dev/da0`
`# gpart show`

```
=>     34  7831485  da0  GPT  (3.7G)
       34     2014       - free -  (1.0M)
     2048  7829464    1  freebsd-ufs  (3.7G)
  7831512        7       - free -  (3.5K)
```
 
This time it starts at 2048, but I still see an uneven remaining block size. Am I missing something.

I will play a little bit with fdisk(8).


----------



## kpa (May 6, 2014)

*Re: Recommendation for GPT alignment of USB-(Flash)-Memstick*

CHS values are an ancient way of expressing a disk geometry in Cylinders/Heads/Sectors.

https://en.wikipedia.org/wiki/Cylinder-head-sector

All modern systems use LBA (logical block addressing) for accessing disks. The method basically treats disks as long arrays of blocks that can be indexed starting from block 1 to the end of the disk. Unfortunately compatibility with the older CHS method has to be still maintained because some BIOSes still insist on enforcing the CHS alignment rules that were once useful when knowing the real geometry of the disk was required to get proper performance out of them. With modern disks the real geometry is never exposed outside the disk and the CHS values are faked usually to somelargenumber/255/63.


----------



## wblock@ (May 6, 2014)

*Re: Recommendation for GPT alignment of USB-(Flash)-Memstick*

The problem is that gpart(8) is very, very standards-oriented, and the MBR standard says "lo, though shalt align thy partitions evenly upon cylinder values, because, hey, times will never change, right?"

So, even if you specify -a4k when creating a partition, gpart() will silently align that partition (slice) with CHS values.  fdisk(8) is from an earlier era, where standards were just, like, your opinion, man.  So it will complain if you tell it to create a partition (slice) starting at block 2048, but it will do it.  Make it a multiple of 1M in size, too.  Or 4K, but 1M will not hurt anything.

FreeBSD installations using MBR typically have BSD partitions inside the slice.  As awful as that is, gpart() will let you align a BSD partition with -a by padding the start of it.


----------



## obsigna (May 7, 2014)

*Re: Recommendation for GPT alignment of USB-(Flash)-Memstick*

I guess, I got it. Thank you @wblock@ and @kpa for the explanations.

In the meantime I did some tests with fdisk(8), forcing the start of the fat32 partition on the 1 MB boundary, almost all devices at home could mount it and read data from it, with the exception of an old car radio, which didn't want to read a .mp3 file from it. So, this finding simply matches what Warren said, many devices don't care about CHS, some old ones do.

Conclusion, on USB pendrives, I will use GPT formatting -b 1M -a 4K for the freebsd-* schemes. FAT32 pendrives for file exchange between different modern OS, shall be force aligned using fdisk, and only the car radio pendrives, I will format leaving alone the naturally odd MBR alignment.


----------

