On Mon, 4 Jan 2010 12:08:05 -0500, Daniel LeBlanc wrote: > Hi, > > On Sun, Jan 3, 2010 at 2:39 AM, Ryusuke Konishi <ryusuke@xxxxxxxx> wrote: > ... > > It still needs backup since NILFS is not of help for hardware > > malfunction. However, I feel it's actually helpful for human errors > > through experiences like that. > ... > > That- I think - is the answer to a question I wanted to ask for some > times now. I've been using XFS for a while now but eventually got bad > sectors on many disks and found XFS to be of limited help when that > happens. So, looking for alternatives I got interested in NILFS > development. Do I understand correctly that NILFS is not really better > than other FS (xfs) when the hardware deteriorates and bad sectors > appear? > > Is it in the plans to somehow 'support' bad sectors reallocation (or such)? > Sorry for my late reply. Nilfs attempts to avoid erroneous segments. If nilfs receives an I/O error properly from the device during write, an error flag is marked for the segment, then allocating the bad segment would be avoided. However, data becomes unreadable if segment deteriorates after write. And, the loss may cause partial data loss, or at worst, make the filesystem totally unreadable. Many drives, in addition, seem to break down more fatally. So, in that sense, I think the level of reliability for hardware malfunction is not much different. Although nilfs redundantly stores past versions of disk blocks for some part, I think redundant drives is necessary in essentials. > ... > > Note that NILFS still lacks fsck. You may go back before filesystem > > corruption, but this is not always possible since some types of > > metadata are not redundant. > ... > > Curious on any scenario you have in mind for such a case to show up? > Hardware malfunction and/or hdd access from outside NILFS? A bug? > Something else? Yes, I have in mind bugs, hardware malfunction, block level override, and so on. Cheers, Ryusuke Konishi -- To unsubscribe from this list: send the line "unsubscribe linux-nilfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
