| |||||||||||||
The 2006 Linux Filesystems Workshop (Part III)The 2006 Linux Filesystems Workshop (Part III)Posted Jul 6, 2006 23:11 UTC (Thu) by vaurora (guest, #38407)In reply to: The 2006 Linux Filesystems Workshop (Part III) by PaulMcKenney Parent article: The 2006 Linux Filesystems Workshop (Part III)
To expand on Arjan's reply, it's not obvious that it would increase the probability of any failure. Sure, there are a larger number of individual bitmaps, but in terms of bits on disk, they are still the same size and shouldn't have an increased likelihood of suffering an I/O error. More superblocks is interesting because they are fixed size per file system; on the other hand, most modern file systems already heavily replicate the superblock. What does seem to be true is that this scheme will limit the effect of any individual failure, as long as we are smart about handling loss of path components.
We definitely appreciate criticism as we would like to figure out (possible fatal) errors BEFORE implementing anything. So if you have any more ideas about how this will fail, let us know and hopefully we can figure something out.
(Log in to post comments)
The 2006 Linux Filesystems Workshop (Part III) Posted Jul 7, 2006 0:20 UTC (Fri) by PaulMcKenney (subscriber, #9624) [Link] My original question came from considering a large file spread across multiple chunks, so that loss of any of these chunks loses part of the file. So any fixed probability of chunk loss adds up (approximately, anyway). On the freelist, I agree with you, and it does seem that you can be more aggressive about replicating superblocks to reduce the probability of superblock loss (but thereby slowing superblock updates).
Idle question, but I couldn't resist asking. ;-)
|
|||||||||||||