Messages in this thread | | | Date | Wed, 17 Feb 1999 22:38:45 -0500 (EST) | From | "Theodore Y. Ts'o" <> | Subject | Re: fsync on large files |
| |
Date: Wed, 17 Feb 1999 17:41:06 -0800 (PST) From: Linus Torvalds <torvalds@transmeta.com>
> Surely ".." is of some value (perhaps not now, but maybe in the > future) to e2fsck is the disk gets corrupted?
Not really. You can use it as an extra sanity-check (and as far as I know fsck does), but that's true of just about any redundant information - that doesn't necessarily make it actually useful. It's less so if you journal your metadata anyway.
So yes, you can use ".." to check that both the parent and the child agree about each other, but even if they don't there's not all that much you can do with the information.
Actually, there is something that can be done with the information; if part of the parent's directory blocks have been corrupted, the child directory will be disconnected from the directory tree. The '..' link will tell you where in the directory tree the child should be reconnected, although not what the name of that child should be.
This information shows up in the fsck transcript, and can be used as a hint by the system administrator about how to restore the disconnected directory from the lost+found directory to the correct place in the directory tree.
I've considered automating this to make it a little easier for system administrators to actually fix things. (For example: reconnecting the directory to the parent directory if possible, and putting a symbolic link in lost+found so the administrator knows where to find the child directory so he/she can rename it to the correct name.)
Even better would be to store the name of the child directory in the child's directory block; this additional amount of redundant information would allow for a completely automated recovery procedure in many cases, which would be a big win.
- Ted
- 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/
| |