Hi,
On 03/18/2016 10:36 PM, Viacheslav Dubeyko wrote:
It needs to dive into state of the volume. You can use lscp and lssu
tools with the goal to retrieve segments and checkpoints state. But,
again, this path could provide opportunity for understanding the bug
essence and environment. I could see only one way for "recovering"
corrupted volume: (1) understand the current state of volume's segments;
(2) localize erroneous segment; (3) try to zero erroneous segment(s) by
means of dd utility; (4) try to mount again. But it's really dangerous
way, you could loose your data.
I could try, but lscp and lssu does not work with this filesystem since
crash. Only 'nilfs-tune -l' display anything.
# strace lssu /dev/loop/1 2>&1 | grep loop
execve("/usr/bin/lssu", ["lssu", "/dev/loop/1"], [/* 61 vars */]) = 0
readlink("/dev/loop", 0x7ffe6a073ac0, 4096) = -1 EINVAL (Invalid argument)
readlink("/dev/loop/1", 0x7ffe6a073ac0, 4096) = -1 EINVAL (Invalid argument)
readlink("/dev/loop", 0x7ffe6a073ac0, 4096) = -1 EINVAL (Invalid argument)
readlink("/dev/loop/1", 0x7ffe6a073ac0, 4096) = -1 EINVAL (Invalid argument)
write(2, "lssu: cannot open NILFS on /dev/"..., 66lssu: cannot open
NILFS on /dev/loop/1: No such file or directory
Does lscp and lssu needs actually mounted filesystem? It does run
readlink() and check /proc/mounts...
-- Piotr.
--
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
