[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
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
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
Thanks again for the detailed response. I learned a ton from this
Main Index |
Thread Index |