On Mon, 14 Jun 1999, Steve Dodd wrote:
> Hi all,
>
> Call me stupid (no - wait until I've finished!), but aren't there major
> problems in the ntfs driver as it stands? As I understand it, the VFS grabs
> the kernel lock for file operations at the moment, so we don't have to worry
> about the SMP situation. However, there are many situations were we access
> things such as the volume bitmap, the mft, the mft bitmap, etc., without
> any locking. As writing to any non-resident attribute will end up calling
> bread(), which can sleep, haven't we got major races?
Pheeeewwww... I've looked into it now. Unfsckingbelievably bad. Yes, there
are races. And *big* ones at it. For a normal filesystem we have several
layers of resources: data in files, namespace metadata, metadata for
files and directories (inodes), allocation metadata for them and
allocation metadata for blocks. VFS takes care of the first two classes
and (more or less) of the third one. The rest is on the responsibility of
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!
> Take cluster allocation for example: we read the relevant part of the bitmap,
> *copy* the data into another memory area, search it, free that memory, re-read
> the same data, copy it again, set the relevant bits, and write it back[1].
>
> While we're sleeping trying to re-read, another task could easily update the
> bitmap, and we wouldn't see the changes. Ack. Presumably this goes for the
> MFT bitmap, too.
>
> I don't understand much about locking in filesystems, but this seems to be
> an obvious no-no?
Yup. Looks like we are deep in 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?
Al
