From: Tomas Pospisek <tpo2@sourcepole.ch>
To: <util-linux@vger.kernel.org>
Subject: making users aware of losetup rw setups?
Date: Wed, 06 Mar 2013 14:31:03 +0100 [thread overview]
Message-ID: <e685cb16a5c23651124fb5ed69469042@sourcepole.ch> (raw)
Hello,
The loopback blockdevice is extremely handy and nice to use, however
there are many allusions on the internets [1] [2], that using a loopback
block device on a disk image in a rw manner is unreliable, i.e. the
loopback device *might eat your data* (!).
This is a kernel/driver issue for sure, however I'd like if that was
documented in the losetup manpage so that users are made aware of the
fact and don't loose their data.
We seem to have been bitten by this problem recently. In our case we
have a LVM partition that contains a disk image. We make a LVM snapshot
of that LVM partition in order to backup it up. Since the LVM partition
contains a disk image with its own partition, we mount the respective
disk-partition with an offset like this:
mount -o offset=1048576 /dev/vg_disks/server_image /mnt/snapshot
I think it is while mounting that we see this:
[65162.184173] Buffer I/O error on device loop0, logical block 3932144
[65162.184297] Buffer I/O error on device loop0, logical block 3932144
[65162.184431] Buffer I/O error on device loop0, logical block 3932158
[65162.184555] Buffer I/O error on device loop0, logical block 3932158
[65162.210044] Buffer I/O error on device loop0, logical block 3932144
[65162.210281] Buffer I/O error on device loop0, logical block 3932158
[65162.210323] Buffer I/O error on device loop0, logical block 3932159
[65162.210373] Buffer I/O error on device loop0, logical block 3932159
[65162.210422] Buffer I/O error on device loop0, logical block 3932159
[65162.210588] Buffer I/O error on device loop0, logical block 3932159
[65162.299517] EXT4-fs (loop0): ext4_orphan_cleanup: deleting
unreferenced inode 81
[65162.299531] EXT4-fs (loop0): 1 orphan inode deleted
[65162.299550] EXT4-fs (loop0): recovery complete
[65162.367689] EXT4-fs (loop0): mounted filesystem with ordered data
mode. Opts: (null)
[65255.139406] quiet_error: 35 callbacks suppressed
[65255.139447] Buffer I/O error on device loop0, logical block 7864304
[65255.139509] Buffer I/O error on device loop0, logical block 7864304
[65255.139578] Buffer I/O error on device loop0, logical block 7864318
[65255.139635] Buffer I/O error on device loop0, logical block 7864318
[65255.141001] Buffer I/O error on device loop0, logical block 7864304
[65255.152388] Buffer I/O error on device loop0, logical block 7864318
[65255.153897] Buffer I/O error on device loop0, logical block 7864319
[65255.155149] Buffer I/O error on device loop0, logical block 7864319
[65255.156447] Buffer I/O error on device loop0, logical block 7864319
[65255.157690] Buffer I/O error on device loop0, logical block 7864319
[65255.270004] EXT4-fs (loop0): ext4_orphan_cleanup: deleting
unreferenced inode 92
[65255.270019] EXT4-fs (loop0): ext4_orphan_cleanup: deleting
unreferenced inode 91
[65255.270023] EXT4-fs (loop0): ext4_orphan_cleanup: deleting
unreferenced inode 90
[65255.270026] EXT4-fs (loop0): ext4_orphan_cleanup: deleting
unreferenced inode 89
[65255.270030] EXT4-fs (loop0): ext4_orphan_cleanup: deleting
unreferenced inode 86
[65255.270033] EXT4-fs (loop0): 5 orphan inodes deleted
[65255.270504] EXT4-fs (loop0): recovery complete
[65255.395442] EXT4-fs (loop0): mounted filesystem with ordered data
mode. Opts: (null)
In short - somehow the FS gets errors from the underlying loop device.
However the layers below the loop device are *not* reporting any errors,
thus one would think it's the loop device itself that is breaking here.
The backups runs every night and we have been seeing this occassionally
- say once a week. A few times it hung the whole machine.
I get the impression that it has been known for at least 5 years that
the loopback block device is broken wrt to writing back to the
underlying layer in edge cases, however there is no up front clear
documentation of that fact. Thus until (if) this will be fixed in the
kernel I would suggest to put a big warning into the losetup man page.
?
Thanks,
*t
[1] http://www.drbd.org/users-guide/ch-configure.html
[2] https://bugs.launchpad.net/wubi/+bug/204133
reply other threads:[~2013-03-06 14:09 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=e685cb16a5c23651124fb5ed69469042@sourcepole.ch \
--to=tpo2@sourcepole.ch \
--cc=util-linux@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox