On Wed, 13 Jul 2016, Michael van Elst wrote:
> Fragments are just the last (partial) block of a file. Fragments from
> multiple files can be combined into a single block to save space,
> especially for small files.
Thanks for replying. I'm assuming then that the metadata for each file
just points to a set of extents, and thus it doesn't matter if the files
are tiny and not occupying a full logical block. Of course, I wonder then
what the point of a logical block is at all. However, I suspect this will
make itself more apparent as I read more code.
> When a file is extended, the partial block may need more space than is
> available or may even require a full block for itself. Then it is
> re-allocated.
That makes good sense and is what I was pretty much expecting. I just
couldn't identify if the reallocation copied the fragment into a new block
or did some kind of pointer magic to truncate the block and point to a new
spot where there was more space. Ie.. I don't know how it works or what
I'm doing and was just groping around trying to understand. :-)
> This has little to do with contiguous block allocation.
Okay, thanks.
> The filesystem code needs to find out wether an operation is allowed.
> You need something like 'user id', 'set of group ids' and 'has superuser
> privileges' for the entity that started the operation, and that's
> abstracted into 'cred'.
Ahhh. Okay. After reading this I found the kauth(9) manual page and Elad
Efrat does a really great job of documenting the kernel authorization
framework. I was Googling and man'ing all the wrong things at first.
> ffs_alloc() panics when called with NOCRED but not FSCRED.
Heh, that part I figured when I saw this 2-liner:
if (cred == NOCRED)
panic("ffs_alloc: missing credential");
However, since I'm pretty unfamiliar with the kernel code or even more
than primitive concepts, I didn't know about the kauth system.
> The code isn't even used for modern hard drives because it doesn't make
> sense with all the hidden buffering and queuing going on.
That's understandable. I was doing some more reading based on this trying
to figure out how you knew that. I looked at ffs_dirpref() which has a lot
of logic and rules around how to hunt for cylinder groups. However, I got
lost pretty quickly. Some of the comments were helpful/insightful, but I'm
not used to reading code this terse and compact with soooo many external
references and includes. Ie.. the kernel is a big project and I've only
done small rinky-dink 30-40 .c and .h file projects, so it's stretching my
limits (a good thing). My own code uses very long and descriptive variable
names and that seems to annoy most other coders. However, it's a good
crutch for when I come back to read something I wrote 6 months back...
It's just my own style and weaknesses showing. I'm not criticizing the
kernel code (I'm not smart enough to do that) !
Right now I'm reading code to understand this:
"
* 2) quadradically rehash into other cylinder groups, until an
* available inode is located.
"
But it's just part of the tour. I'll figure it out or ask more intelligent
questions. Thanks again for your insight and help.
-Swift
