On 30/12/21 11:00 pm, Peter Grandi wrote: >> Trying to mount a NILFS partition > To be pedantic, but it matters, it is "block device" in UNIX-like > systems, and more "NILFS2 instance", as here could be multiple > NILFS2 instances even in a single block device (but that is a > very rare setup usually requiring 'losetup' mounts). Correct, being sloppy here in my terminology, it's a block device which is a RAID-1 (+ dmcrypt/luks) which gives me confidence that the underlying hardware is ok. >> fails with "couldn't mount because of unsupported optional >> features (477e7ad1e859f753)". [...] > That does not look a lucky situation. You can use 'lscp > /dev/...' to list the checkpoints and try to mount an older > checkpoint with 'mount -t nilfs2 -o cp=... /dev/... ...' to > mount it and resume work from that. In theory older checkpoints > will be fully consistent even if the latest one is corrupted. Thanks Peter, it seems both lscp and mount -o cp need a functioning super block though. > Unless that message means that the NILFS2 instance is corrupted > because of "issues" (usually hardware, most common with block > devices on USB storage devices). I might dig into this a little deeper, the data isn't that important but gaining a correct understanding of NILFS working principles is. My understanding so far was that it's quite hard for data to become entirely inaccessible. This looks like a good idea, linear scan for segment nodes: https://www.spinics.net/lists/linux-nilfs/msg02198.html Could be the start of the fsck that never happened. -- h.
