Re: UFS fragments

[mlelstv%serpens.de@localhost (Michael van Elst)]

swiftgriggs%gmail.com@localhost (Swift Griggs) writes:


>I've been studying ffs_alloc.c in the kernel source. I was trying to 
>understand how the logical block allocation in UFS works. I never actually 
>knew about "fragments". I get why they are there, but I have some 
>questions if anyone has time:

>* I notice that fragments can be re-allocated. Could that create 
>  fragmentation issues ? Is there a way to change allocations so that 
>  they are physically contiguous? Not that this matters much anymore. I'm 
>  just curious if it was ever an issue. 

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.

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.

This has little to do with contigous block allocation.


>* I see "cred" (type kauth_cred_t) being passed around a lot in the API 
>  calls. What is that doing? Aren't all these calls already going to be 
>  operating as root? I couldn't find the meaning of "NOCRED" in 
>  /usr/include/*.h or significant info related to kauth_cred_t but I'm 
>  probably just looking in the wrong places. I'm thinking this is puffs 
>  related, but I didn't think puffs and UFS knew each other.

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'.

NOCRED means that no credentials are available because the operation
isn't related to a LWP.

FSCRED means that this is an internal filesystem operation, also
not related to a LWP.

In either case, no credentials exist that could be checked.
kauth will just allow such an operation.

ffs_alloc() panics when called with NOCRED but not FSCRED.

Places where FSCRED is used, are the allocation of the
in-volume journal for WAPBL and the allocation of backing
store for a filesystem snapshot.



>* I see some code that seem to be related to spinning rust. Like this 
>  line: 
>  " *   2) allocate a rotationally optimal block in the same cylinder."

>  Are there many opportunities for optimizing for SSD, nowadays, or is it 
>  just too much trouble for not enough payoff?

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.

I doubt that this code could help SSDs.


-- 
-- 
                                Michael van Elst
Internet: mlelstv%serpens.de@localhost
                                "A potential Snark may lurk in every tree."