Re: retry mounting with ro when rw fails
on 08/04/2011 03:00 Jeremy Chadwick said the following: On Thu, Apr 07, 2011 at 01:20:53PM -0700, Garrett Cooper wrote: On Thu, Apr 7, 2011 at 10:25 AM, Andriy Gapon a...@freebsd.org wrote: [sorry for double post, it should have been hackers not hardware] Guys, could you please review and comment on the following patch? http://people.freebsd.org/~avg/mount-retry-ro.diff Thank you! The patch consists of two parts. The first part is in CAM/SCSI to make sure that ENODEV is consistently returned to signal that an operation is not supported by a device (in accordance to intro(2)) and specifically to return ENODEV on write attempt to a read-only or write-protected media. ?Making this change in SCSI should cover real SCSI devices, as well as ATAPI through ahci/siis/atapicam or similar, plus majority (all?) of USB Mass Storage devices. The second part is in vfs_mount code. ?The idea is to re-try a mount call if we get the ENODEV error, and mounting was not already in read-only mode, and there was no explicit rw or noro option; the second try is changed to ro. I did only basic testing with an SD card in write-protected mode and a USB card-reader. ?Since I am not very familiar with vfs_mount code I might have missed some important details. As a generic question / observation, maybe we should just implement 'errors=remount-ro' (or a reasonable facsimile) like Linux has in our mount(8) command? Doesn't look like NetBSD, OpenBSD, or [Open]Solaris sported similar functionality. I was going to recommend exactly this. :-) I like the idea of Andriy's patch, but would feel more comfortable if it were only used if a mount option was specified (-o errors=remount-ro). Having the option is appealing, but my main motivation was the simplicity that comes from having that enabled by default. That is, you absolutely want an R/W mount then use -o rw, you need R/O then explicitly -o ro, you just want to get that media mounted then the default behavior tries its best. Why: Are there any conditions where ENODEV is returned to the underlying vfs layer for things like unexpected hardware issues? I would imagine the latter would be ENXIO, but I'm not certain. An example situation: 1. User inserts USB flash drive/etc. 2. User tries to mount disk R/W manually 3. Weird/bizarre hardware issue happens mid-mount (drive falling off the bus, or maybe even the user yanking the drive right in the middle) -- could this ever return ENODEV? It shouldn't. If that happens then the underlying layers should be fixed. 4. Kernel attempts re-mount, which also fails, or possibly panics due to some underlying condition which nobody predicted 5. User mails mailing list If I'm worrying over nothing, then perfect. :-) My other concern is whether or not this mechanism change could caused some sort of infinite loop within devd(8)/devctl(4) where the daemon gets very confused as to what's going on or some automated commands get run when they shouldn't. I can't see how that can happen. -- Andriy Gapon ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: retry mounting with ro when rw fails
on 08/04/2011 05:16 Garrett Cooper said the following: Yeah. It seems like something else like EINVAL (just an example -- probably a bad one) would be better. Also, please be careful as returning ENODEV seems to be UFS-specific: I wonder how you arrived at that conclusion. See intro(2) or grep the sources. The following errors can occur for a ufs file system mount: [ENODEV] A component of ufs_args fspec does not exist. That documented specific use of ENODEV in UFS doesn't make ENODEV UFS-specific. Besides I don't ENODEV anywhere under sys/ufs. Also, Tom Rhodes has a similar change to what I suggested on the backburner, but it hasn't been 100% fleshed out yet. I like that approach too. It has its advantages. But I don't give up yet on my suggestion. -- Andriy Gapon ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: retry mounting with ro when rw fails
on 07/04/2011 23:20 Garrett Cooper said the following: As a generic question / observation, maybe we should just implement 'errors=remount-ro' (or a reasonable facsimile) like Linux has in our mount(8) command? Doesn't look like NetBSD, OpenBSD, or [Open]Solaris sported similar functionality. No problem, I am OK with being first. Then, I only want to deal with media that is semi-permanently or permanetly read-only. That's why I handle only failure to mount media as R/W. But from what I read 'errors=remount-ro' in Linux has to do with errors that happen after filesystem is mounted. That is, you mounted a filesystem, you work with it, you get some error (e.g. because of bad blocks), you auto-downgrade the filesystem to readonly. This may be a nice feature, but this is something different from what I proposed. And, AFAIK, Linux does what I propose by default, without any additional options. Google for block device ... is write-protected, mounting read-only. But yes, it seems that they handle this situation entirely in userland. And I am not against it. -- Andriy Gapon ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: retry mounting with ro when rw fails
On Fri, 8 Apr 2011, Andriy Gapon wrote: on 08/04/2011 03:00 Jeremy Chadwick said the following: On Thu, Apr 07, 2011 at 01:20:53PM -0700, Garrett Cooper wrote: As a generic question / observation, maybe we should just implement 'errors=remount-ro' (or a reasonable facsimile) like Linux has in our mount(8) command? Doesn't look like NetBSD, OpenBSD, or [Open]Solaris sported similar functionality. I was going to recommend exactly this. :-) I like the idea of Andriy's patch, but would feel more comfortable if it were only used if a mount option was specified (-o errors=remount-ro). Having the option is appealing, but my main motivation was the simplicity that comes from having that enabled by default. That is, you absolutely want an R/W mount then use -o rw, you need R/O then explicitly -o ro, you just want to get that media mounted then the default behavior tries its best. But the default behaviour is backwards, especially for read-mostly removable media. The default should be ro, possibly with an automagic upgrade to rw iff the media really needs to be written too. Writing timestamps for file system and inode access times doesn't count as really needs to be written to. I think I prefer requiring an explicit upgrade to rw. rw implies writing access times unless you also use noatime, and I wouldn't want noatime to be set automagically depending on whether rw is set explicitly, so I would want noatime to be set explicitly, and once you do that then you can easily set rw or ro at the same time. A new rm (read mostly) or rwa (read or write automagically) flag could give automatic upgrade from ro to rw. I'd also like automatic downgrade to ro after a file system has not been written to for some time (this would avoid fscks in most cases for read-mostly file systems. The ro flag should be per-cylinder-group in ffs so that on big disks, most parts are read-only most of the time and don't need to be checked). Bruce ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
RE: retry mounting with ro when rw fails
I had been letting this discussion settle a little bit before jumping in, but we've done some work in this area for a few of our platforms. The work was rather ham-fisted, but I've been looking for a way to try to get it cleaned up and back to FreeBSD. Basically, we have a way of detecting that our disk is physically write-protected, a pretty common scenario. Given that, I made some surgical changes to the mount path to prevent read-write mounts of the disk at all. You can't allow that, because even attempts to update the superblock or timestamp will fail and leave buffers outstanding. Over time, this eventually panics the system. My implementation simply drops the read-write flag and mounts the FS readonly, rather than return a failure (which stopped the startup RC scripts). What I was hoping to do was design a better mechanism for passing that R/O detection from the device to the filesystem code. Our implementation uses a platform sysctl that checks the incoming device name against some hardware or software settings. Ick. I don't know enough about device/GEOM calls to do it better though. ... Andrew Duane Juniper Networks o +1 978 589 0551 m +1 603-770-7088 adu...@juniper.net -Original Message- From: owner-freebsd-hack...@freebsd.org [mailto:owner-freebsd-hack...@freebsd.org] On Behalf Of Bruce Evans Sent: Friday, April 08, 2011 8:20 AM To: Andriy Gapon Cc: Garrett Cooper; freebsd...@freebsd.org; Jeremy Chadwick; FreeBSD Hackers Subject: Re: retry mounting with ro when rw fails On Fri, 8 Apr 2011, Andriy Gapon wrote: on 08/04/2011 03:00 Jeremy Chadwick said the following: On Thu, Apr 07, 2011 at 01:20:53PM -0700, Garrett Cooper wrote: As a generic question / observation, maybe we should just implement 'errors=remount-ro' (or a reasonable facsimile) like Linux has in our mount(8) command? Doesn't look like NetBSD, OpenBSD, or [Open]Solaris sported similar functionality. I was going to recommend exactly this. :-) I like the idea of Andriy's patch, but would feel more comfortable if it were only used if a mount option was specified (-o errors=remount-ro). Having the option is appealing, but my main motivation was the simplicity that comes from having that enabled by default. That is, you absolutely want an R/W mount then use -o rw, you need R/O then explicitly -o ro, you just want to get that media mounted then the default behavior tries its best. But the default behaviour is backwards, especially for read-mostly removable media. The default should be ro, possibly with an automagic upgrade to rw iff the media really needs to be written too. Writing timestamps for file system and inode access times doesn't count as really needs to be written to. I think I prefer requiring an explicit upgrade to rw. rw implies writing access times unless you also use noatime, and I wouldn't want noatime to be set automagically depending on whether rw is set explicitly, so I would want noatime to be set explicitly, and once you do that then you can easily set rw or ro at the same time. A new rm (read mostly) or rwa (read or write automagically) flag could give automatic upgrade from ro to rw. I'd also like automatic downgrade to ro after a file system has not been written to for some time (this would avoid fscks in most cases for read-mostly file systems. The ro flag should be per-cylinder-group in ffs so that on big disks, most parts are read-only most of the time and don't need to be checked). Bruce ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: retry mounting with ro when rw fails
on 08/04/2011 15:20 Bruce Evans said the following: But the default behaviour is backwards, especially for read-mostly removable media. The default should be ro, possibly with an automagic upgrade to rw iff the media really needs to be written too. Writing timestamps for file system and inode access times doesn't count as really needs to be written to. I think I prefer requiring an explicit upgrade to rw. rw implies writing access times unless you also use noatime, and I wouldn't want noatime to be set automagically depending on whether rw is set explicitly, so I would want noatime to be set explicitly, and once you do that then you can easily set rw or ro at the same time. A new rm (read mostly) or rwa (read or write automagically) flag could give automatic upgrade from ro to rw. I'd also like automatic downgrade to ro after a file system has not been written to for some time (this would avoid fscks in most cases for read-mostly file systems. The ro flag should be per-cylinder-group in ffs so that on big disks, most parts are read-only most of the time and don't need to be checked). This is a very good idea, I would like to get that too, but it's a bit more work than the auto-mounting. -- Andriy Gapon ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: retry mounting with ro when rw fails
on 08/04/2011 15:36 Andrew Duane said the following: What I was hoping to do was design a better mechanism for passing that R/O detection from the device to the filesystem code. Our implementation uses a platform sysctl that checks the incoming device name against some hardware or software settings. Ick. I don't know enough about device/GEOM calls to do it better though. I am actually not aware of any way to inquiry write-protection status from hardware. There are distinct SCSI sense codes for that, but you get them only after a failed write attempt. But there are many things that I don't know about... -- Andriy Gapon ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
RE: retry mounting with ro when rw fails
For SCSI-attached disks, yes. But other hardware has write-protect sensing (SD cards, CD-roms, our platform). So if you can do that, you should Cleaning up after a failed write is a real problem, one that I needed to avoid. /Andrew -Original Message- From: Andriy Gapon [mailto:a...@freebsd.org] Sent: Friday, April 08, 2011 11:23 AM To: Andrew Duane Cc: Bruce Evans; freebsd...@freebsd.org; FreeBSD Hackers; freebsd-s...@freebsd.org Subject: Re: retry mounting with ro when rw fails on 08/04/2011 15:36 Andrew Duane said the following: What I was hoping to do was design a better mechanism for passing that R/O detection from the device to the filesystem code. Our implementation uses a platform sysctl that checks the incoming device name against some hardware or software settings. Ick. I don't know enough about device/GEOM calls to do it better though. I am actually not aware of any way to inquiry write-protection status from hardware. There are distinct SCSI sense codes for that, but you get them only after a failed write attempt. But there are many things that I don't know about... -- Andriy Gapon ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: retry mounting with ro when rw fails
On Thu, Apr 7, 2011 at 10:25 AM, Andriy Gapon a...@freebsd.org wrote: [sorry for double post, it should have been hackers not hardware] Guys, could you please review and comment on the following patch? http://people.freebsd.org/~avg/mount-retry-ro.diff Thank you! The patch consists of two parts. The first part is in CAM/SCSI to make sure that ENODEV is consistently returned to signal that an operation is not supported by a device (in accordance to intro(2)) and specifically to return ENODEV on write attempt to a read-only or write-protected media. Making this change in SCSI should cover real SCSI devices, as well as ATAPI through ahci/siis/atapicam or similar, plus majority (all?) of USB Mass Storage devices. The second part is in vfs_mount code. The idea is to re-try a mount call if we get the ENODEV error, and mounting was not already in read-only mode, and there was no explicit rw or noro option; the second try is changed to ro. I did only basic testing with an SD card in write-protected mode and a USB card-reader. Since I am not very familiar with vfs_mount code I might have missed some important details. As a generic question / observation, maybe we should just implement 'errors=remount-ro' (or a reasonable facsimile) like Linux has in our mount(8) command? Doesn't look like NetBSD, OpenBSD, or [Open]Solaris sported similar functionality. Thanks, -Garrett ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: retry mounting with ro when rw fails
On Thu, Apr 07, 2011 at 01:20:53PM -0700, Garrett Cooper wrote: On Thu, Apr 7, 2011 at 10:25 AM, Andriy Gapon a...@freebsd.org wrote: [sorry for double post, it should have been hackers not hardware] Guys, could you please review and comment on the following patch? http://people.freebsd.org/~avg/mount-retry-ro.diff Thank you! The patch consists of two parts. The first part is in CAM/SCSI to make sure that ENODEV is consistently returned to signal that an operation is not supported by a device (in accordance to intro(2)) and specifically to return ENODEV on write attempt to a read-only or write-protected media. ?Making this change in SCSI should cover real SCSI devices, as well as ATAPI through ahci/siis/atapicam or similar, plus majority (all?) of USB Mass Storage devices. The second part is in vfs_mount code. ?The idea is to re-try a mount call if we get the ENODEV error, and mounting was not already in read-only mode, and there was no explicit rw or noro option; the second try is changed to ro. I did only basic testing with an SD card in write-protected mode and a USB card-reader. ?Since I am not very familiar with vfs_mount code I might have missed some important details. As a generic question / observation, maybe we should just implement 'errors=remount-ro' (or a reasonable facsimile) like Linux has in our mount(8) command? Doesn't look like NetBSD, OpenBSD, or [Open]Solaris sported similar functionality. I was going to recommend exactly this. :-) I like the idea of Andriy's patch, but would feel more comfortable if it were only used if a mount option was specified (-o errors=remount-ro). Why: Are there any conditions where ENODEV is returned to the underlying vfs layer for things like unexpected hardware issues? I would imagine the latter would be ENXIO, but I'm not certain. An example situation: 1. User inserts USB flash drive/etc. 2. User tries to mount disk R/W manually 3. Weird/bizarre hardware issue happens mid-mount (drive falling off the bus, or maybe even the user yanking the drive right in the middle) -- could this ever return ENODEV? 4. Kernel attempts re-mount, which also fails, or possibly panics due to some underlying condition which nobody predicted 5. User mails mailing list If I'm worrying over nothing, then perfect. :-) My other concern is whether or not this mechanism change could caused some sort of infinite loop within devd(8)/devctl(4) where the daemon gets very confused as to what's going on or some automated commands get run when they shouldn't. -- | Jeremy Chadwick j...@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP 4BD6C0CB | ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: retry mounting with ro when rw fails
On Thu, Apr 7, 2011 at 5:00 PM, Jeremy Chadwick free...@jdc.parodius.com wrote: On Thu, Apr 07, 2011 at 01:20:53PM -0700, Garrett Cooper wrote: On Thu, Apr 7, 2011 at 10:25 AM, Andriy Gapon a...@freebsd.org wrote: [sorry for double post, it should have been hackers not hardware] Guys, could you please review and comment on the following patch? http://people.freebsd.org/~avg/mount-retry-ro.diff Thank you! The patch consists of two parts. The first part is in CAM/SCSI to make sure that ENODEV is consistently returned to signal that an operation is not supported by a device (in accordance to intro(2)) and specifically to return ENODEV on write attempt to a read-only or write-protected media. ?Making this change in SCSI should cover real SCSI devices, as well as ATAPI through ahci/siis/atapicam or similar, plus majority (all?) of USB Mass Storage devices. The second part is in vfs_mount code. ?The idea is to re-try a mount call if we get the ENODEV error, and mounting was not already in read-only mode, and there was no explicit rw or noro option; the second try is changed to ro. I did only basic testing with an SD card in write-protected mode and a USB card-reader. ?Since I am not very familiar with vfs_mount code I might have missed some important details. As a generic question / observation, maybe we should just implement 'errors=remount-ro' (or a reasonable facsimile) like Linux has in our mount(8) command? Doesn't look like NetBSD, OpenBSD, or [Open]Solaris sported similar functionality. I was going to recommend exactly this. :-) I like the idea of Andriy's patch, but would feel more comfortable if it were only used if a mount option was specified (-o errors=remount-ro). Why: Are there any conditions where ENODEV is returned to the underlying vfs layer for things like unexpected hardware issues? I would imagine the latter would be ENXIO, but I'm not certain. An example situation: 1. User inserts USB flash drive/etc. 2. User tries to mount disk R/W manually 3. Weird/bizarre hardware issue happens mid-mount (drive falling off the bus, or maybe even the user yanking the drive right in the middle) -- could this ever return ENODEV? 4. Kernel attempts re-mount, which also fails, or possibly panics due to some underlying condition which nobody predicted 5. User mails mailing list If I'm worrying over nothing, then perfect. :-) My other concern is whether or not this mechanism change could caused some sort of infinite loop within devd(8)/devctl(4) where the daemon gets very confused as to what's going on or some automated commands get run when they shouldn't. Yeah. It seems like something else like EINVAL (just an example -- probably a bad one) would be better. Also, please be careful as returning ENODEV seems to be UFS-specific: The following errors can occur for a ufs file system mount: [ENODEV] A component of ufs_args fspec does not exist. Also, Tom Rhodes has a similar change to what I suggested on the backburner, but it hasn't been 100% fleshed out yet. Thanks, -Garrett ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
