On Mon, Jun 14, 1999 at 11:56:12AM -0400, Alexander Viro wrote:
> fs driver. And for normal filesystems we can get out pretty easy - a
> single lock is enough. But here... Arrgh. AFAICS there are recursive
> dependencies of almost arbitarary depth. Down, not across!
The wonders of NTFS - the inodes are stored in what is for all intents and
purposes, a normal file. Unnnngh.
> Yup. Looks like we are deep in it.
I've just done some stupid tests - run three processes writing to three files
in parallel - and I've discovered something else that bites us: the driver
calls kmalloc(..., GFP_KERNEL), which can (and does) sleep, so there are
all sorts of odd places where we can sleep without expecting it.
> Steve, could you describe the
> data structures involved (i.e. the layout of fs - no details, just what is
> there and what depends on what)? I suspect that it will be the fastest way
> (invitation includes everybody, indeed). OK?
Mmmm. I think it might be easier just to pull the thing apart and make it
pass buffer_heads around, rather than allocing and copying data willy-nilly.
But for the record:
Files can have multiple attributes, or streams, but the $DATA attribute holds
the normal file contents.
Attributes either have their contents in-inode ('resident') if they are small
enough, or are non-resident, in which case a 'run-list' is stored in-inode
instead giving the ranges of blocks (a.k.a clusters) used for the data.
Inodes 0 - 0xa are system files; inodes 0xb - 0xf are used for extending
inode 0 if its run-list (extents list) overflows its inode (usually 1k, 4k
on older versions of NT).
The inodes themselves are stored in the $DATA attribute of inode 0 (the system
file $MFT), sequentially. Inode 0 ($MFT) has a $BITMAP attribute which marks
which inodes are in use and which aren't. Inodes have a 'generation' number
which gets incremented on disk when they're recycled, so this should make NFS
less problematical, at least.
The volume bitmap is stored in the data attribute of inode 5 (system file
$Bitmap)..
So:
- the bitmaps need protecting; if we were to pass buffers around presumably
we can just lock the buffer while we're using the bitmap (what happens to
this sort of thing when you take the big kernel lock away from the fs
stuff..?)
- there shouldn't be a problem with two processes writing back different
inodes to $MFT, the thing we have to watch out for (and lock) is when we
have to extend the MFT to make way for more inodes.
My brain hurts.
--
20962296
