NetBSD-Users archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: Beating a dead horse

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.


Home | Main Index | Thread Index | Old Index