Skip to content

xfs mount fails for read-only devices #17

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
martinpitt opened this issue Sep 10, 2012 · 2 comments
Closed

xfs mount fails for read-only devices #17

martinpitt opened this issue Sep 10, 2012 · 2 comments

Comments

@martinpitt
Copy link

You cannot mount read-only devices such as write protected SD cards, CD-ROMs, etc. with XFS. This is currently being detected by the udisks2 test suite which tries to do fs creation and mounting for r/w and r/o devices.

If you want to reproduce this on Linux without any hardware, here are the steps (as root) to prepare a virtual readonly device:

modprobe scsi_debug dev_size_mb=100

now check dmesg for the device that it created; usually /dev/sdb

mkfs.xfs -L testro /dev/sdb

now create a readonly CD-ROM like device:

echo 5 > /sys/bus/pseudo/drivers/scsi_debug/ptype
echo 1 > /sys/bus/pseudo/drivers/scsi_debug/add_host

now check dmesg for the created CD-ROM device, usually /dev/sr1

try to mount it:

mount -t xfs /dev/sr1 /mnt

This gives:

mount: block device /dev/sr1 is write-protected, mounting read-only
mount: /dev/sr1: can't read superblock

Explicitly specifying -r (readonly) also doesn't help; the first line disappears, but the "can't read superblock" error is still happening.

Tested with a rather old 2.20.1, and confirmed with current git master.

@karelzak
Copy link
Collaborator

On Mon, Sep 10, 2012 at 06:39:54AM -0700, Martin Pitt wrote:

You cannot mount read-only devices such as write protected SD cards,
CD-ROMs, etc. with XFS. This is currently being detected by the
udisks2 test suite which tries to do fs creation and mounting for
r/w and r/o devices.

It's usually better to report bugs by upstream mailing list or by
a distribution bug tracking system.

If you want to reproduce this on Linux without any hardware, here
are the steps (as root) to prepare a virtual readonly device:

modprobe scsi_debug dev_size_mb=100

now check dmesg for the device that it created; usually /dev/sdb

mkfs.xfs -L testro /dev/sdb

now create a readonly CD-ROM like device:

echo 5 > /sys/bus/pseudo/drivers/scsi_debug/ptype
echo 1 > /sys/bus/pseudo/drivers/scsi_debug/add_host

now check dmesg for the created CD-ROM device, usually /dev/sr1

try to mount it:

mount -t xfs /dev/sr1 /mnt

Try

LIBMOUNT_DEBUG=0xffff mount -r -t xfs /dev/sr1 /mnt

you will see that mount(8) calls mount(2) syscall and the syscall
returns EIO error and kernel is pretty verbose about the problem (see dmesg output).

[1678391.647219] XFS (sr0): Mounting Filesystem
[1678391.670926] XFS (sr0): xfs_do_force_shutdown(0x1) called from line 1031 of file fs/xfs/xfs_buf.c. Return address = 0xffffffffa09a999a
[1678391.670943] XFS (sr0): I/O Error Detected. Shutting down filesystem
[1678391.670951] XFS (sr0): Please umount the filesystem and rectify the problem(s)
[1678391.670961] XFS (sr0): metadata I/O error: block 0x19022 ("xlog_bwrite") error 5 buf count 2097152
[1678391.671646] XFS (sr0): failed to locate log tail
[1678391.671654] XFS (sr0): log mount/recovery failed: error 5
[1678391.671809] XFS (sr0): log mount failed

Not sure how I can help you. It would be better to talk about it with
kernel XFS developers (linux-fs list).

Explicitly specifying -r (readonly) also doesn't help; the first
line disappears, but the "can't read superblock" error is still
happening.

mount(8) successfully detects that the device is read-only (the first
attempt to the mount device ends with EROFS, second attempt is with
MS_RDONLY flag). Anyway, the option -r allows to save one syscall.

mount -t xfs /dev/sr0 /mnt/test

mount: /dev/sr0 is write-protected, mounting read-only
mount: /dev/sr0: can't read superblock

Karel

Karel Zak kzak@redhat.com
http://karelzak.blogspot.com

@martinpitt
Copy link
Author

Hello Karel,

Karel Zak [2012-09-11 2:09 -0700]:

It's usually better to report bugs by upstream mailing list or by
a distribution bug tracking system.

Ah sorry, I saw a couple of other issues and thought that this was the
current upstream bug tracker.

LIBMOUNT_DEBUG=0xffff mount -r -t xfs /dev/sr1 /mnt

you will see that mount(8) calls mount(2) syscall and the syscall
returns EIO error and kernel is pretty verbose about the problem (see dmesg output).

Ah, thanks for the hint about LIBMOUNT_DEBUG!

Not sure how I can help you. It would be better to talk about it with
kernel XFS developers (linux-fs list).

Right, so let's close this issue, as the bug is not in util-linux.

Sorry for the noise!

Martin

Martin Pitt | http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants