Re: Beating a dead horse

[Swift Griggs <swiftgriggs%gmail.com@localhost>]

On Wed, 25 Nov 2015, Greg Troxel wrote:
> So there are two issues: alignment and filesystem block/frag size, and 
> both have to be ok.

Ahh, a key point to be certain.

> So that's ok, but alignment is messier.

It sure seems that way!  :-)

>  We're seeing smaller disks with 4K sectors or larger flash erase blocks 
> and 512B interfaces now.

Those larger erase blocks (128k?!) would seem to be a big problem if you'd 
rather stick to a smaller alignment or file system block size. However, 
maybe I'm missing something about the interplay between things like inode 
sizes and any relationship with the erase block size. For example, if you 
were using an 8K block size I'd think a 128k erase block size would blow 
things up nicely when you blew way past the 8k block you originally wanted 
to clear. Again, however, I feel I'm missing something, but let me say 
right away that I'm ingratiated by your detailed response and I learned 
much from it.

> That avoids the alignment issue, but requires filesystem/kernel support. 
> I am pretty sure netbsd-7 is ok with that but I am not sure about 
> earlier.

Interesting. For some reason I have it in my head that many EMC SANs of 
various stripes (and I know for sure the XtremeIO stuff) uses 4k block 
sizes. I've used NetBSD in the past in EMC environments and seen moderate 
(but not what I'd call "high") performance vis-a-vis other (Linux and/or 
Solaris) hosts. I wonder if this was a factor. I'll have to test with 
Netbsd 7, now. Sounds fun.

> It would probably be possible to add a call into drivers to return this 
> info and propagate it up and have newfs/fdisk query it.

That sounds pretty automagical (in a good way). However, as you point out 
it might be tedious for not enough payoff considering that using a 2048 
offset seems to address the issue.

> Certainly you are welcome to read the code and think about it if this 
> interests you - just explaining why I think no one has done the work so 
> far.

I did, in fact, take a look at /usr/src/sbin/newfs/mkfs.c and 
/usr/include/ufs/ffs as well. I'm a kernel lightweight and I got all 
confused by discussions in the code about block fragments and minimum / 
maximum block sizes. Here I was thinking all that was static. I did learn 
that 4k seems to be the smallest allowable size (line 141 in fs.h #define 
MINBSIZE 4096). It sounds like that's the smallest since a cylinder group 
block struct needs a 4k space to be workable. I also noticed that 
superblock sizes seem to operate independently of the data block sizes. 
It's a great day for learning!

> I geuss you can put it that way, saying otherwise we would always start 
> at 2048 and use 32K or even 64K blocks.

That doesn't seem too wasteful to me, but I'm ready for some embedded 
systems guy to lecture me.  :-)

> But I think part of it is inertia.  And the the 63 start dates back to 
> floppies that had 63-sector tracks - so it was actually aligned.

Ahhhh! I always wondered where that came from. I remember floppy disk 
controllers were bizarre animals. Physical characteristics were 
so important that you could easily create differences that'd result in a 
completely unreadable floppy. Ie.. that was always a big issue trying to 
get my Amiga floppies to read on a PC. I had to buy a special dual-mode 
floppy controller et al.... After all that hassle I still have some stupid 
emotional affinity for 3.5" floppies because of how much more wonderful 
they seemed over 5.25" floppies. Ugh... nostalgia can be painful sometimes 
:-P

Thanks again for the detailed response. I learned a ton from this 
discussion.

Thanks,
  Swift