On Sun, Oct 15, 2023 at 7:55 PM Martin Vahi wrote: > > > The symptoms are that a NilFS2 partition at a multi-TiB-sized USB-HDD that > has only one huge primary partition, the NilFS2 partition, > fails to mount. The symptoms include: > > ----start--of--citation--of--dmesg--output--last--lines--- > [ 382.418297] usb 2-2: new high-speed USB device number 5 using xhci_hcd > [ 382.611471] usb 2-2: New USB device found, idVendor=152d, idProduct=578e, bcdDevice=14.05 > [ 382.611480] usb 2-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3 > [ 382.611485] usb 2-2: Product: External USB 3.0 > [ 382.611489] usb 2-2: Manufacturer: Intenso > [ 382.611493] usb 2-2: SerialNumber: 20171113252B4 > [ 382.616077] scsi host7: uas > [ 382.617099] scsi 7:0:0:0: Direct-Access Intenso External USB 3.0 1405 PQ: 0 ANSI: 6 > [ 382.617889] sd 7:0:0:0: Attached scsi generic sg3 type 0 > [ 382.618920] sd 7:0:0:0: [sdc] 1220942646 4096-byte logical blocks: (5.00 TB/4.55 TiB) > [ 382.619085] sd 7:0:0:0: [sdc] Write Protect is off > [ 382.619086] sd 7:0:0:0: [sdc] Mode Sense: 5f 00 00 08 > [ 382.619391] sd 7:0:0:0: [sdc] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA > [ 382.619619] sd 7:0:0:0: [sdc] Optimal transfer size 33550336 bytes > [ 382.673809] sdc: sdc1 > [ 382.675211] sd 7:0:0:0: [sdc] Attached SCSI disk > [ 486.063294] NILFS (sdc1): mounting unchecked fs > [ 486.099403] NILFS (sdc1): invalid segment: Magic number mismatch > [ 486.099413] NILFS (sdc1): trying rollback from an earlier position > [ 486.100080] NILFS (sdc1): invalid segment: Magic number mismatch > [ 486.100081] NILFS (sdc1): error -22 while searching super root > [ 1034.270149] NILFS (sdc1): mounting unchecked fs > [ 1034.313297] NILFS (sdc1): invalid segment: Magic number mismatch > [ 1034.313308] NILFS (sdc1): trying rollback from an earlier position > [ 1034.314722] NILFS (sdc1): invalid segment: Magic number mismatch > [ 1034.314726] NILFS (sdc1): error -22 while searching super root > ----end----of--citation--of--dmesg--output--last--lines--- > > From an 2012_07_23 mailing list post at > > https://www.mail-archive.com/linux-nilfs@xxxxxxxxxxxxxxx/msg01243.html > > it seems that the way to may be the solution is to use > "ddrescue" for creating an image of the whole device and then > mount that HDD-image. As of 2023_10_15 I do not know, if that > "ddrescue" based solution works for me, because I do not have > big-enough empty HDD at and to try it, but the referenced > mailing list post is over 10 years old and it can be expected > that an USB-HDD that has its own power supply, can loose > power at any moment or its USB-cable can be detached > at any moment, so I suspect that there just has to be > some more elegant solution to this naturally occurring > problem than to create a HDD-image of a multi-TiB sized HDD. > > My problem is that I fail to find that solution, despite > surfing the mailing list archive and reading the various > NilFS related documentation. Could anybody please provide some > links to related documentation, messages at the mailing list archive > or please provide some other hints or ideas, how I can mount > my USB-HDD without waiting a whole week or two for it to > get copied to some bigger HDD and then back again. Thank You. > > > Yours sincerely, > Martin.Vahi@xxxxxxxxxx The log messages indicate that the situation is quite severe. > [ 486.099403] NILFS (sdc1): invalid segment: Magic number mismatch This message indicates that the magic number in the header of the log pointed to by a superblock is abnormal, that is, the log data is corrupted on disk. > [ 486.099413] NILFS (sdc1): trying rollback from an earlier position > [ 486.100080] NILFS (sdc1): invalid segment: Magic number mismatch > [ 486.100081] NILFS (sdc1): error -22 while searching super root And this message indicates that although recovery was attempted using a spare superblock, the previous log pointed to by that pointer was also corrupted. Therefore, the data immediately before the problem probably has not been written to the disk, and cannot be salvaged. NILFS2 is designed to write log data to media and then update the superblock pointer, and to be safe, the superblock is duplicated so that you can retroactively mount logs from a while ago. It's rare that either of these remedies doesn't work, and this usually doesn't happen even with a sudden power cut. Normally, even with a disk cache, this will not happen if the minimum guaranteed write ordering and flushing semantics are properly guaranteed. There may be probably a bug in the device driver or the disk firmware, or the disk may not be reliable to begin with. Or perhaps the data that was supposed to have been written to the media was unfortunately corrupted retroactively. If there is no backup, the only way to rescue old data is to manually rewrite the number of the last segment number (and associated checkpoint and sequence numbers) in superblocks and successfully mount it with read-only and norecovery mount options. Unfortunately, there is no easy way to recover from this level of destruction. Since it cannot be mounted, the lssu command cannot be used to determine the state of segments. Instead, try checking the status with the nilfs-tune and dumpseg commands: $ sudo nilfs-tune -l /dev/sdc1 will list information written in a superblock. And, $ i=0; while [ $i -lt 511 ]; do sudo dumpseg /dev/sdc1 $i | head -4; let i=i+1; done writes out information (such as sequence number and creation date and time) for segments with valid logs. Here, 511 is the number of segments, so use the value in the "Number of segments:" field in the nilfs-tune output for your device. This will give you an overview of the logs (segments) written to disk. Try dumping the information of the segment that appears to be the newest using dumpseg without the head command, and look for the segment containing "ino = 3" (the inode number of that DAT metadata file written at the end of the checkpointed log). For instance, if the 100th segment appears to be the newest, try the following: $ sudo dumpseg /dev/sdc1 100 Since manually rewriting the segment pointer in a superblock is a dangerous operation, I will omit it here. I think it is important to first understand the current situation. Regards, Ryusuke Konishi
