Re: UFS fragments

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

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