file system shenanigans (was: Re: [PLUG] ELF Init section)

[gabriel rosenkoetter <gr@eclipsed.net>]

You'd really think I'd have learned not to presume I knew things
by now tonight, but I clearly haven't. ffs and lfs both default to
whatever you set bsize to in the disk's disklabel which, in a
default install of NetBSD at least, is 8192 bytes. I'm going to go
ahead and presume that ufs has some similar kind of way of deciding,
though I haven't a clue what it is. Though I've created a ufs disk
on a Solaris machine, it's all a bit hazy.

The problem here is that we're talking about two different things.
du doesn't report blocks in the sizes the file system likes, but
in the sizes it was compiled to show them. On BSD- and System
V-derived systems, this defaults to 512b blocks. On all the Linux
systems I've used, it seems to default to 1K blocks. On every system
trying to be POSIX compliant, du -k reports in 1K blocks.

Does this imply that the ext2 file systems on all the Linux systems
I've used are using 1K blocks on disk? I doubt it. It's just what
whoever wrote GNU's du decided was appropriate (because it's easier
for a human to understand? I guess, but only because we've become
power-of-(about)-ten-byte centric in the 90s).

I'm still distantly curious about why the default block sizes for
ext2 are what they are (does this make ext2 deal with a wider
variety of disks better with less user intervention? seems like a
program-that's-trying-to-be-too-smart problem would come up awfully
quickly that way), but I guess I'm more curious about what workloads
call for what block sizes (and fragment sizes, and cylinders per
group, and so forth). Any conventional or experimental wisdom on
that?

       ~ g r @ eclipsed.net


______________________________________________________________________
Philadelphia Linux Users Group       -      http://www.phillylinux.org
Announcements-http://lists.phillylinux.org/mail/listinfo/plug-announce
General Discussion  -  http://lists.phillylinux.org/mail/listinfo/plug