> 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/