| |||||||||||
Other error rates that need to be looked at.Other error rates that need to be looked at.Posted Jul 6, 2006 21:03 UTC (Thu) by smoogen (subscriber, #97)Parent article: The 2006 Linux Filesystems Workshop (Part III)
Actually I was wondering if another issue a filesystem might be looking at is the integrity of other data on the disk. The FSuCK checks and fixes the integrity of the metadata on a disk, but does it check the integrity of the data inside a file? And should a file-system worry about this due to the growing percentage of 'noise' that is showing up in the file-system?
[A silly idea comes to mind with the filesystem broken into several virtual layers aimed. The lowest level layer sort of RAID's the read/writes across the disk (versus disks). The next layer deals with the standard filesystem actions and the top layer interfaces with VFS. This might have some value at a time when users have 2+ TB of diskspace in their home computer that they are storing their collections of movies etc and just want to make sure that the video doesnt crash out because some bits error'd out after a bit.]
(Log in to post comments)
Other error rates that need to be looked at. Posted Jul 6, 2006 23:01 UTC (Thu) by valhenson (subscriber, #38407) [Link] 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.
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 (guest, #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.
|
|||||||||||