Messages in this thread | | | Date | Sun, 17 Jan 1999 03:06:31 -0500 (EST) | From | Alexander Viro <> | Subject | Re: [RFC] What should we do with FAT inode numbers? |
| |
On Sun, 17 Jan 1999, Albert D. Cahalan wrote:
> 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/
| |