> Yes, silly_rename on the directory. Though it is ugly, this startegy
> gives good inode number behavior.
>
> The only other idea that came close used the first cluster and
> preallocated a cluster every time an empty file is encountered.
> This is worse than the above: allocate on stat() just in case
> someone opens the file, and use a timeout to deallocate again!
;-<<<
Albert, WTF do we need inumbers compatible with the current scheme, after
al? Why do we need working iget() on FAT-derived ones? Look: icache must
be searchable only if we need to recognize the situation when dentry
should hang on inode of another dentry instead of reading its own copy.
That's for normal filesystems. For FAT we don't have inode-level links, so
searchable icache is a dubious advantage here. Perhaps we shouldn't use
iget() at all. It's usages in FAT are very untypical and IMHO we would be
better off with an alternative function for inodeless filesystems. Other
obvious candidate being NCPFS (and maybe SMBFS). We already have
get_empty_inode() for sockets and pipes.
iget() is used for initial inode allocation (both lookup() and
create()/mkdir()) and for checking that entry is used by unlinked inode.
The first usage is not exactly iget(). The second one goes away. We are
getting a new one: from readdir(). BFD. Use find_inode_number() (already
written for NCPFS). Another (tricky) one being VFAT aliases. That's a bit
worse, but we may create both short and long dentry when we get a positive
lookup. BTW, it would remove the need in invalidate() there - upon
successful lookup() we'll try to find another dentry, allocating a new one
if not found. Thus if we got a negative short dentry sometime ago we'll
convert it into positive one automatically.
So I think that we simply don't need iget() there. All we need is
a function that would allocate a new struct inode and give it unique
i_ino. Since those inodes have no business sitting in main hash we can
give a separate list/hash for them (e.g. for uniqueness checks). We will
need to drop inode as soon as i_count becomes 0. Doable with almost zero
changes.
> I'll take silly_rename over that for sure.
What about the solution above? I agree that silly_rename() may be useful
and probably needs generalizing. I *don't* want to take part in yet
another code duplication in fs/*/*. There's way too many duplicated code
right now and it has an unpleasant property: fixes do not propagate into
copies. It is evil. silly_rename() mechanism is an ad-hocery and I'ld
rather wait with it till 2.3.
> > FAT doesn't have hardlinks, so...
>
> Umsdos has problems there with hardlinks.
Look at them someday. They are symlinks in disguise. Work is done via
dcache layer, not inode one, so they are not a problem.
> >> The NFS solution is better, and it keeps the same inode number.
> >> It also reduces the time during which a crash would leave lost
> >> clusters in the FAT.
> >
> > You'll get bloody unpleasant rmdir with that startegy. And lots of
> > nasty code (look through fs/nfs/dir.c for silly_rename() and friends).
>
> It would not be so bad. No other machine will crash or delete
> the renamed files.
Really? I hope you do realise that in VFAT directory entries
related to any given file may be in different sectors, so crash may very
well screw the directory structure (partial update). It's not an
FFS-derivative, so no alignmenmt for you.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/