mkfs.fat: changing sec_per_track problematic

[jku]

I'm not sure if this really is a bug in dosfstools, maybe you can help with that.

The latest release changes the default sectors-per-track value to 63 and master has a commit that seems to make it depend on target size. Can you explain why these need to be done -- isn't this value cosmetic by now?

Yocto generates images with "mkfs.fat" and then uses "mcopy" to copy data to them. mcopy has a sanity check to make sure total sector count is divisible by sectors-per-track. It's becoming very difficult to make the image size correct when the sectors-per-track keeps changing based on version of dosfstools...

Is it possible to give the caller more control over sectors-per-track, or would you say "mcopy" is wrong to do the sanity check it does?

[andreasbombe]

Yes, the value is pretty much cosmetic. The defaults used to be 64/32 when formatting a file image and 255/63 when formatting a block device. When I got rid of the broken device detection code prior to 4.0 the default ended up being 255/63. That ended up breaking the Debian installer build because of mtools. So I thought it would be nice anyway to have smaller filesystems not get the LBA dummy values just for aesthetic reasons.

Yes, the check in mtools is bogus. The filesystem size not being divisible by sectors-per-track is not an error. It means that such a filesystem on a device where heads and cylinders actually count (like floppies) would waste a few sectors. It should be, at best, a warning on floppies, and even that is questionable.

Turning the check off in mtools, like everyone else does, would be the way to go. I might implement switches to set the heads and sectors-per-track values just for completeness anyway.

[jku]

Thanks for your insight: I'll manhandle mcopy to do the right thing instead.