Hi Vyacheslav, On Tuesday 24 of July 2012 10:26:37 you wrote: > I am afraid that it is not so good from the end user point of view. > > First of all, the message "mount: /dev/sda3: can't read superblock" can > confuse user. The reason is bad sectors inside the volume but user is > informed about impossibility to read superblock. > > Secondly, it is possible situation when it really needs to use a volume > in the case of presence of bad sectors. And I think that users can > expect such NILFS behavior because of declared reliability. > > Unfortunately, as I can understand, NILFS hasn't bad blocks table and > can't process situation of bad blocks presence on volume correctly. It > means that NILFS interprets bad blocks as exceptional case. But from my > point of view, it makes sense to interpret bad blocks as usual thing and > try to work in the presence of ones. For example, fsck potentially can > check NILFS volume on bad blocks presence, construct bad blocks table > and save it on the volume. > > I suggest to add "virtual" special file for bad blocks description. It > can be described by inode in ifile and all bad blocks can be described > in DAT file as parts of this "virtual" special file. So, as a result, > NILFS file system driver will have bad blocks table which can be a basis > for excluding bad blocks from operation and trying to survive in the not > good device environment. > > What do you think about such idea? I believe bad sectors to be thing of the past mostly; any decent harddrive (probably also any decent SSD) should re-map them after some re-reads. Some data & meta-data loss is possible, but overall the FS should be accessible again. I have no idea why my particular HDD did not re-map; perhaps it just takes much longer than I gave it. As a point of reference, XFS does not do bad block management either; however, the partition driver of IRIX does bad sector management -- so it is implemented one layer below the FS. I guess it /may be/ possible to use Linux' `dm' driver in such manner. Cheers, -- dexen deVries [[[↓][→]]] "all dichotomies are either true or false" is a true paradox because it's paradoxical only if it is a paradox ;) -- 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
