| |||||||||||||
|
| |||||||||||||
Other error rates that need to be looked at.Other error rates that need to be looked at.Posted Jul 6, 2006 23:01 UTC (Thu) by vaurora (subscriber, #38407)In reply to: Other error rates that need to be looked at. by smoogen Parent article: The 2006 Linux Filesystems Workshop (Part III)
The integrity of data can be checked as well, if we have checksums for it. There are a lot of options for doing this. I like the following two best:
Checksum in the indirect block pointing to the data block
Optional per-file checksum updated on close, invalidated by a write or writable mmap() - gets gross with large write-mostly files like logs
As for your ideas about layers, check out the architecture of ZFS:
http://www.opensolaris.org/os/community/zfs/source/
At the workshop, we talked a little bit about creating a more useful volume manager interface (i.e., not one that looks exactly like a dumb disk). We also talked about working with manufacturers to improve the interfaces to dumb disks in ways that file systems find useful.
(Log in to post comments)
Other error rates that need to be looked at. Posted Jul 8, 2006 11:27 UTC (Sat) by job (subscriber, #670) [Link] I am intrigued by the ZFS design. What is the pros/cons of moving DM-type functionality into the FS layer?
Other error rates that need to be looked at. Posted Jul 8, 2006 17:51 UTC (Sat) by giraffedata (subscriber, #1954) [Link] Several times in the article and comments, I've seen the implication that FSCK corrects errors -- at least metadata errors -- in a filesystem. But FSCK as I understand it hardly does that at all. It corrects inconsistencies, and sometimes it corrects an inconsistency by replacing a lost and redundant piece of metadata. But there isn't that much redundancy in e.g. ext2, is there? If a disk error or system crash causes a filesystem to lose a file's inode, FSCK "corrects" that error by deleting all the file's blocks too, right? As a consistency restorer, there's nothing FSCK can do with file data -- from the filesystem perspective, the data is always consistent no matter how much it gets corrupted.
Other error rates that need to be looked at. Posted Sep 5, 2006 21:48 UTC (Tue) by anton (subscriber, #25547) [Link] from the filesystem perspective, the data is always consistent no matter how much it gets corrupted.Yes, many file system designers only care about metadata consistency. Note how doublefs is suggested as a replacement for copy-on-write filesystems, even though doublefs only duplicates the metadata; with update-in-place for data, I don't really see an efficient way to guarantee that the data is consistent.
|
|
||||||||||||