Re: [9fans] lnfs

[presotto@plan9.bell-labs.com]

[-- Attachment #1: Type: text/plain, Size: 681 bytes --]

I'm not sure what you mean by flush, fprint is synchronous.
I could retry the write if you like, though there's not
much likelyhood that it would work the second time if
it didn't the first, there's no lock on .longnames,
it's append only, so a failure is probably the fs or
someone having removed the file.

.longnames is also written before the file is created,
so the name should be there should you find the hashed
file when reading the dir.

However, in rreaddir, I don't reread the file while
translating the short names to long ones.  Someone
could create a file while I'm busy converting the
dir.  There's plenty of window there for someone to
sneak through.

[-- Attachment #2: Type: message/rfc822, Size: 1727 bytes --]

From: nigel@9fs.org
To: 9fans@cse.psu.edu
Subject: [9fans] lnfs
Date: Tue, 1 Oct 2002 09:18:49 +0100
Message-ID: <97967b679371324c95efff80d254b753@9fs.org>

Is it expected that lnfs can support several instances of it running
on the same file tree?

It looks that way in that it reloads the the name file before walks
and creates.

But there is no retry around the write of a new entry in newname().
So one instance might create a long named file, and fail to flush it
to .longnames.  Another instance would then not have a translation for
the base32 name it finds in the directory during a walk.

I accept that the windows are small, but I'm searching for an
explanation for some strange behaviour I saw yesterday.