Re: virtual device both is and isn't a valid file system [complete]
Hi.
On Tue, May 14, 2019 at 09:52:10AM -0700, Ross Boylan wrote:
> Here's the info:
Nothing interesting in the strace output, short of:
<strace output>:
...
mount("/dev/mapper/stretch--vg-boot",
"/root/tempserver-check/stretch_boot", "ext4", 0, NULL) = -1 EIO
(Input/output error)
...
The reason being - EIO return code is not documented in the mount(2).
Well, mount(1) said something about that 'other error' as a possible
reason of failure, but the clarity of the message is something that's
left to be desired here.
But this (when in doubt - always check dmesg. Userspace can and will
lie. Trust the kernel):
> root@barley:~/tempserver-check# dmesg | tail
...
> [74940.130661] block nbd3: Write on read-only
> [74940.130666] print_req_error: I/O error, dev nbd3, sector 22843394
> [74940.130671] Buffer I/O error on dev dm-30, logical block 1, lost
> sync page write
> [74940.130677] EXT4-fs (dm-30): I/O error while writing superblock
> [74940.130684] EXT4-fs (dm-30): mount failed
combined with this:
> root@barley:~/tempserver-check# e2fsck -fn /dev/stretch-vg/boot
> e2fsck 1.44.5 (15-Dec-2018)
> Pass 1: Checking inodes, blocks, and sizes
> Pass 2: Checking directory structure
> Pass 3: Checking directory connectivity
> Pass 4: Checking reference counts
> Pass 5: Checking group summary information
> /dev/stretch-vg/boot: 345/97536 files (0.3% non-contiguous),
> 116077/389120 blocks
and this (note -r here):
> qemu-nbd -v -r --fork -c ...
and this:
> mount /dev/stretch-vg/boot stretch_boot
Brings me to the following:
1) One cannot mount an ext* filesystem in read-write mode (it's the
default) unless an underlying block device is also in read-write mode.
Your PV is read-only, that's the source of your problem.
2) One can mount an ext* filesystem in read-only mode, assuming that
it's clean. Currently that's your case, so
mount -r /dev/stretch-vg/boot stretch_boot
should work for you.
3) Both fsck (with -n option), and dump(1) should work here too.
4) But to escape the future confusion I suggest you to loose that '-r'
flag in qemu-nbd. And to backup that 'vdi' image beforehand, just in
case.
Reco
Reply to: