OK given that most of the information provided by drive manufacturers is largely manipulated to make them all seem better than they actually are.
Actually, that's false. Disk drive manufacturers do indeed use terms that make their drives look good. For example, they have the habit of measuring capacity in
metric gigabytes or terabytes, rather than in
binary. which makes an 6-8% difference. Their statements about capacity are true, but they set unrealistic expectations: If I buy a 1 terabyte disk drive, I might expect to be able to store 1024 files, each of which are 1024x1024x1024 bytes long, but the drive will fill up when I have written 10^12 bytes. The drive vendor is not being dishonest, and their statements about drive capacity are true. Similarly, their statements about performance, reliability and error rates are nearly always true, and when they are false, they tend to get into big trouble with large customers. I've seen disk drive manufacturers (name withheld to protect the guilty) have to refund the purchase price on tens of thousands of drives at a time, and then pay their customer millions of $ to buy drives from the competition. For this reason, manufacturers work really hard to be honest in verifiable statements. Now, their glossy sales literature sometimes has beautiful pictures of green meadows, with cute blond girls holding flowers and deer contentedly munching grass, and statements like "enterprise storage reliability and performance at commodity prices". Anybody who believes that you can get all three of good/fast/cheap is as dumb as someone who thinks that their new disk drive comes shipped with bambi or barbie. And the marketing departments of disk drive vendors hope to exploit dumb customers
what gpart -a actually does.
See above in the answers by others. It simply tells
gpart where to put partition boundaries.
But that size can often be chosen. Most frequently; 512 bytes, or 4 KiloBytes.
That's 99% wrong, and 1% right.
I'll refer to what you're talking about as the
sector size. I know that the term is inaccurate, and standards documents call it the logical or physical
block size, but the term sector is engrained in the language, and at a hardware level, the recorded data is actually partitioned into something that we'll call sector. Reading and writing a sector is typically an atomic operation, which is why the sector size is relevant to correctness. Consumer drives come pre-formatted with a sector size of 512 or 4096 bytes (4096 is more recent), although some drives use 4096 bytes in the hardware of the platter, but expose a 512 byte sectors on the interface (and fix the difference with some magic, which usually involves read-modify-write and the judicious use of NVRAM or flash, and is often known as 4096e or emulated drives).
Most drives allow the user to change the sector size, within limits. Sector sizes of 520 and 528 bytes are not uncommon in the enterprise market. With the advent of PI a.k.a. T10-DIF and similar data integrity mechanisms, the physical sector sizes have been increasing. The user is free to use a format command to change the sector size of the drive. On FreeBSD, the
camcontrol format command does not directly support format commands that change the sector size, the user has to implement that with
camcontrol cmd and assemble the command from the drive documentation (a bit tedious). On Linux, or after installing the sg_utils package on FreeBSD, this can be easily done with
sg_format. But: the sector size can usually only be changed in a narrow range. On 512-byte sector disks, you can go up to 528 (I've never seen anyone use higher number), not to 700 or 800. On 4K sector disks, it gets even more tricky.
Ideally, the chosen BLOCK/SECTOR size reflects the size of the majority of the files that will occupy it. A 4k SECTOR/BLOCK size is best suited for larger files, where 512b, is best for many small files.
That depends on the definition of small files. There are systems where everything below 1GiB is considered a small file. I know of no serious production file systems where 4K is considered a large file. From a raw disk performance point of view, the performance threshold is often the cylinder: IOs are considered large if they involve multiple cylinders, because then a whole cylinder can be read or written independent of rotational position, where small IOs will have significant rotation delay. With typical cylinder sizes on modern disks being a quarter or a half MB, that shows the the boundary for small IOs is in the MB range. From a blocking point of view, the performance threshold is having to perform read-modify-write operations on an atomic block. The block size varies widely, most commodity file systems have at least a 4KiB VM page size as the smallest accessible unit, but once RAID gets involved, block sizes can be as large as 16 MiB. And RAID always gets involved on "large" systems, as anything larger than a few drives becomes too unreliable for production use if you want your file system to actually be persistent in the long run.
You have to remember: Sensible file systems are able to store small files in the metadata (typically inside the inode). So a 512 byte file may actually not be a file at all, as seen from the on-disk IOs.
Drive manufacturers of more recent models, assume that most consumers use their drives primarily to store porn, and ripped MP3s.
You are off by a few orders of magnitude there. And you are focusing on a part of the market that is visible to the amateur, but not seriously relevant to the industry as a whole.
To begin with, a typical ripped MP3 file is multiple megabytes in size. I just checked for fun on my home server: Of the 3567 ripped tracks (I'm a classical and band music fan with a large CD collection), only 120 or 3% are smaller than 1MiB. Unfortunately, I have no porn on my server (sadly), but looking at home movie clips (band performances, my kid's soccer games), the typical file size seems to be hundreds of MB. This is between 3 and 5 (decimal) orders of magnitude away from the 512 byte / 4 KB sector size transition.
Second, the market of consumers storing data on their desktop is beginning to be irrelevant to the industry. Today, most data is stored by enterprises (whether they're called "Blue Cross" or "Facebook"). And while in the end they also store documents (scanned paper documents, photos, and videos stored by youtube.com), they tend to use file and storage systems that are much more complex than what the individual end user sees (which is a commodity file system, whether it's called NTFS or UFS, using a single drive).
So they manufacture them with a default SECTOR/BLOCK size of 4k. Whereas in the "olden" days, porn, and ripped MP3s were harder to come by. So they sent them out primarily with a 512b SECTOR/BLOCK size.
The transition to 4K sectors was not really driven by the change in file sizes, and in particular not by the internet-delivered workloads of porn and music. For many years, file systems have been dealing in 4K VM pages anyhow, so the 512 bytes have not been relevant for a while. The transition was driven by disk hardware, in particular the much higher data densities (due to new heads, platter materials, and magnetics), which make short sectors terribly inefficient. Do I like the new 4K sectors? No, for me it is a hassle having to adapt to them. But they are a necessity if you want to store a half-dozen terabytes for a small stack of $20 bills.
But on a recent partition/newfs on a USB SSD I attempted to use -a 1M. Thinking that I'd have a drive aligned on a One MegaByte boundary. But it appeared to end up on a 512b boundary.
Your statement is hard to parse. If you align to a 1MiB boundary, it will also align to a 512b boundary, as 1MiB is an integer multiple of 512 bytes.
And: All I wrote above is relevant to what I lovingly call "spinning rust", namely traditional disk drives. You are using SSDs or memory sticks. While they also have physical block sizes, their hardware is very different, and has other characteristics. A very important consideration in them is "write amplification", which for serious use should probably the driving factor in block size and alignment decisions, given that other than read-modify-write operations on their physical blocks (which are usually way larger than the 512 bytes or 4K they expose on their interface), their performance is not heavily dependent on sequential versus random IO.
Can I accomplish the same with gpart(8) across an entire drive? As in
