Messages in this thread | | | Date | Sun, 17 Jan 1999 00:58:12 -0500 (EST) | From | "Albert D. Cahalan" <> | Subject | Re: [RFC] What should we do with FAT inode numbers? |
| |
Alexander Viro writes:
> Hmm... OK, folks. What about the following? > a) we don't give any warranties about preserving inode number of opened > file.
OK.
To avoid this, one could reserve the directory slot originally used to open the file until the file is closed. Subsequent calls to open can return the original inode number, no matter what the current on-disk value is.
> b) for linked files we use the coordinates of directory entry. > c) when file gets unlinked we change its inode number so that it would not > clash with the inodes of linked files (mod 32 trick). We make those inode > numbers unique (32*event++ + 1, if it is already used - add powers of two, > then - linear search (should be very rare)). Oh, we do it only if there > are other owners of inode, indeed.
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.
I note that Linux does not currently support the dirty flag:
Field Offset Length Physical Drive Number 36 1 Current Head 37 1 <--- now a dirty flag Signature 38 1 ID 39 4 Volume Label 43 11 System ID 54 8
The low order bit is a dirty flag, used to indicate that autochk should run chkdsk against the volume at boot time.
The second lowest bit is a flag indicating that a surface scan should also be run.
(this is NT 4... I believe Win9x uses the other 6 bits to choose what FAT is active)
- 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/
| |