Hi, On Tue, 2012-07-24 at 09:06 +0900, Ryusuke Konishi wrote: > On Mon, 23 Jul 2012 20:24:10 +0200, dexen deVries wrote: > > Hi again, > > > > > > I've copied the whole filesystem elsewhere (to a file) with `ddrescue'. It > > found > > one damaged area on the drive, but apparently neither at start nor at the > > end > > of partition. > > > > The FS on the drive was marked as `dirty' (requiring recovery upon mount). > > My > > guess is that kernel attempted recovery, and gave up upon read error. > > > > Unfortunately, the `norecovery' option did not help with the drive; it only > > helped once i've moved whole FS to file. > > > > > > Log from ddrescue: > > > > > > # Rescue Logfile. Created by GNU ddrescue version 1.14 > > # Command line: ddrescue /dev/sdc3 sda3 sda3.log > > # current_pos current_status > > 0x149E0CCC00 + > > # pos size status > > 0x00000000 0x149E0CC000 + > > 0x149E0CC000 0x00001000 - > > 0x149E0CD000 0x11220D3000 + > > > > > > my understanding is, the following line describes the damaged area, format: > > start length status-marker (`-' for error) > > 0x149E0CC000 0x00001000 - > > > > > > Once the FS was copied to a file, it mounted correctly: > > # mount -o ro,loop,norecovery ./sda3.img ./some-mountpoint > > > > > > My gripe with current (linux-3.5.0) NILFS2 driver is that I couldn't tell > > it > > to ignore read errors and thus force it to mount the filesystem. > > Good point. The current recovery logic is intentionally implemented > so that it aborts when having met an I/O error.
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? With the best regards, Vyacheslav Dubeyko. > > This treatment should not be applied at least if the norecovery option > is specified. > > Thanks, > Ryusuke Konishi > > > Ony after I've > > moved some 160GB of FS to a file (that's a bit tedious :P) it opened the FS > > just fine. > > > > > > Cheers, > > -- > > dexen deVries > > > > 1972 - Dennis Ritchie invents a powerful gun that shoots both forward and > > backward simultaneously. Not satisfied with the number of deaths and > > permanent > > maimings from that invention he invents C and Unix. > > -- > > To unsubscribe from this list: send the line "unsubscribe linux-nilfs" in > > the body of a message to majord...@vger.kernel.org > > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- > To unsubscribe from this list: send the line "unsubscribe linux-nilfs" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-nilfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
