12:37 p.m.
I have a system used for backups, and when it boots it *may* have any or all of
a number of small hot-swap RAID storage units connected by eSATA. Ideally I
would like the system to fsck and mount these when present, using the UUID=
option in fstab. There's a problem. If the units are not connected the system
tried to fsck them anyway, considers them missing, and doesn't complete boot.
Defining the mount as "noauto" doesn't help, the boot still tries to do the
fsck, and still fails. Moreover, I really want the unit mounted if present.
Next I set the fsck field to 0, which does prevent unwanted fsck, but also
doesn't fsck even when the unit is attached and detected. More "doesn't do
what
I want" behavior.
I might be able to hack the behavior I want into udev, but it would be a real
non-standard behavior there.
I thought the 'nofail' option would solve the problem, but that appears to be a
very recent option, and not in RHEL running on this server.
Any thoughts gratefully accepted, we try to keep vital infrastructure running on
RHEL rather than Fedora, for obvious reasons of stability and avoiding having to
upgrade and re-certify every six months.
--
Bill Davidsen <davidsen(a)tmr.com>
We are not out of the woods yet, but we know the direction and have
taken the first step. The steps are many, but finite in number, and if
we persevere we will reach our destination. -me, 2010
12:43 p.m.
On 02/23/2013 12:37 PM, Bill Davidsen wrote:
I thought the 'nofail' option would solve the problem, but
that appears
to be a very recent option, and not in RHEL running on this server.
Any thoughts gratefully accepted, we try to keep vital infrastructure
running on RHEL rather than Fedora, for obvious reasons of stability and
avoiding having to upgrade and re-certify every six months.
https://www.redhat.com/mailman/listinfo/rhelv6-list
--
========================================================================
Ian Pilcher arequipeno(a)gmail.com
Sometimes there's nothing left to do but crash and burn...or die trying.
========================================================================
12:45 p.m.
On Sat, 23 Feb 2013 13:37:29 -0500
Bill Davidsen wrote:
Defining the mount as "noauto" doesn't help, the boot
still tries to do the
fsck, and still fails. Moreover, I really want the unit mounted if present.
The fsck is (I believe) controlled independently from noauto
by one of the two obscure numbers on the end of the mount
line (which may actually be documented in the fstab
man page).
Using noauto though means it won't mount it at all. You'd
have to do something like put a mount command in /etc/rc.d/rc.local
that could simply fail if the device isn't connected.
1:24 p.m.
Tom Horsley wrote:
On Sat, 23 Feb 2013 13:37:29 -0500
Bill Davidsen wrote:
> Defining the mount as "noauto" doesn't help, the boot still tries to do
the
> fsck, and still fails. Moreover, I really want the unit mounted if present.
The fsck is (I believe) controlled independently from noauto
by one of the two obscure numbers on the end of the mount
line (which may actually be documented in the fstab
man page).
It is, that's what I was mentioning in the 2nd paragraph, the fsck field
controls the order in which checks are done before mounting, to be sure that
mounts on mounts obey the law of least astonishment. (Plauger's Law)
Using noauto though means it won't mount it at all. You'd
have to do something like put a mount command in /etc/rc.d/rc.local
that could simply fail if the device isn't connected.
Yes, that was an attempt to avoid the hang on boot, what I really need is more
complex, and I may have to put it in rc.local to make it work, although I will
test on Fedora using the nofail option. As I look at the RHEL world, I expect
RHEL7 to be along before too long. Perhaps that would satisfy all requirements.
It depends on what the 'nofail' option does if the UUID is present but doesn't
pass fsck, is it reported and ignored or does it hang the boot?
Thanks for the reply.
--
Bill Davidsen <davidsen(a)tmr.com>
"We have more to fear from the bungling of the incompetent than from
the machinations of the wicked." - from Slashdot
4:15 p.m.
On 24/02/13 06:24, Bill Davidsen wrote:
...
Yes, that was an attempt to avoid the hang on boot, what I really
need
is more complex, and I may have to put it in rc.local to make it work,
although I will test on Fedora using the nofail option. As I look at the
RHEL world, I expect RHEL7 to be along before too long. Perhaps that
would satisfy all requirements.
It depends on what the 'nofail' option does if the UUID is present but
doesn't pass fsck, is it reported and ignored or does it hang the boot?
Hey Bill, I see you are after a RHEL solution, but does any of these
things you tried work on Fedora 17 or 18 ?
I wasn't able to do what you are trying to do on F16 or F17, either boot
deciding it can't complete (which is really incorrect because the
partitions needed to boot the machine and load user home dirs are
mounted and usable - it's just the optional backup mount that isn't), or
the drive not mounted at all.
I also realized there is no hot-plug mounting, because it wasn't plugged
after a user logged in. And if it hot plugged, then it' is mounted for
just that user under /var/somewhere ...
You would also want to ensure the drive isn't mounted if fsck was going
to run. Doing it outside the boot process would be good, because then it
wouldn't pause the boot process until your ~1TB drive is fscked...
2:01 p.m.
David Timms wrote:
On 24/02/13 06:24, Bill Davidsen wrote:
...
> Yes, that was an attempt to avoid the hang on boot, what I really need
> is more complex, and I may have to put it in rc.local to make it work,
> although I will test on Fedora using the nofail option. As I look at the
> RHEL world, I expect RHEL7 to be along before too long. Perhaps that
> would satisfy all requirements.
> It depends on what the 'nofail' option does if the UUID is present but
> doesn't pass fsck, is it reported and ignored or does it hang the boot?
Hey Bill, I see you are after a RHEL solution, but does any of these
things you tried work on Fedora 17 or 18 ?
fc1[78] have the "nofail" option in fstab, which on paper does what I
want. I
have to set up a test system, or test case on a system, so I can verify that the
result is what I want, but it looks like the logic is what I want, "if the
device/UUID is present, do thus with it, else ignore it."
I wasn't able to do what you are trying to do on F16 or F17,
either boot
deciding it can't complete (which is really incorrect because the
partitions needed to boot the machine and load user home dirs are
mounted and usable - it's just the optional backup mount that isn't), or
the drive not mounted at all.
Using the option, or trying to do it otherwise.
I also realized there is no hot-plug mounting, because it wasn't
plugged
after a user logged in. And if it hot plugged, then it' is mounted for
just that user under /var/somewhere ...
For me that's not an issue, the drives in the array are hot swap, but the boxes
holding the array are not, so I'm always starting from power-on boot state.
You would also want to ensure the drive isn't mounted if fsck was
going
to run. Doing it outside the boot process would be good, because then it
wouldn't pause the boot process until your ~1TB drive is fscked...
The time to recover typical issues in a journaled filesystem is minimal, if the
f/s is really borked there will be an admin present during the boot anyway. And
these arrays would typically be checked in case of any visible issues anyway,
like unclean shutdown. The array would be checked, then the filesystem on it.
--
Bill Davidsen <davidsen(a)tmr.com>
"We have more to fear from the bungling of the incompetent than from
the machinations of the wicked." - from Slashdot
2:21 p.m.
On 02/25/2013 12:01 PM, Bill Davidsen wrote:
>
The time to recover typical issues in a journaled filesystem is minimal,
if the f/s is really borked there will be an admin present during the
boot anyway.
What are the boxes set to do when power is restored after a failure?
Stay off, turn on, or return to whatever state they were in before? I'm
asking because of a possibility your statement brought to mind. I don't
know about you, but I live in earthquake country.[1][2] Let's say
there's a major quake and breakers pop. When they get reset, backup
power reaches the boxes. If they come back up and need to get
thoroughly fscked, will there be an admin capable of dealing with it?
[1]Everyplace is earthquake country if you wait long enough.
[2]In my case, the San Andreas Fault.
(http://en.wikipedia.org/wiki/San_Andreas_Fault for those of you
unfamiliar with it.)
5:19 p.m.
Joe Zeff wrote:
On 02/25/2013 12:01 PM, Bill Davidsen wrote:
>>
> The time to recover typical issues in a journaled filesystem is minimal,
> if the f/s is really borked there will be an admin present during the
> boot anyway.
What are the boxes set to do when power is restored after a failure? Stay off,
turn on, or return to whatever state they were in before? I'm asking because of
a possibility your statement brought to mind. I don't know about you, but I
live in earthquake country.[1][2] Let's say there's a major quake and breakers
pop. When they get reset, backup power reaches the boxes. If they come back up
and need to get thoroughly fscked, will there be an admin capable of dealing
with it?
Since these machines hold backup copies of data, hopefully they don't need to
be
up immediately. If needed there will be someone present to supervise, although
if the RAID boxes are connected they could be powered on remotely, manually
fsck'd, and mounted.
My main concern is avoiding doing things manually which the computer can do for
me. It doesn't get tired, or bored, need bifocals to read serial numbers off the
boxes, etc. I like the idea of plugging in a box and starting the server, and
having everything just come up.
[1]Everyplace is earthquake country if you wait long enough.
[2]In my case, the San Andreas Fault.
(http://en.wikipedia.org/wiki/San_Andreas_Fault for those of you unfamiliar with
it.)
--
Bill Davidsen <davidsen(a)tmr.com>
"We have more to fear from the bungling of the incompetent than from
the machinations of the wicked." - from Slashdot
5:46 p.m.
On 02/26/2013 03:19 PM, Bill Davidsen wrote:
>
Since these machines hold backup copies of data, hopefully they don't
need to be up immediately. If needed there will be someone present to
supervise, although if the RAID boxes are connected they could be
powered on remotely, manually fsck'd, and mounted.
I presume, then, that they don't start up on their own after a power
failure. Thanx for the answer.
9:20 p.m.
Bill Davidsen wrote:
Tom Horsley wrote:
> On Sat, 23 Feb 2013 13:37:29 -0500
> Bill Davidsen wrote:
>
>> Defining the mount as "noauto" doesn't help, the boot still tries
to do the
>> fsck, and still fails. Moreover, I really want the unit mounted if present.
>
> The fsck is (I believe) controlled independently from noauto
> by one of the two obscure numbers on the end of the mount
> line (which may actually be documented in the fstab
> man page).
>
It is, that's what I was mentioning in the 2nd paragraph, the fsck field
controls the order in which checks are done before mounting, to be sure that
mounts on mounts obey the law of least astonishment. (Plauger's Law)
> Using noauto though means it won't mount it at all. You'd
> have to do something like put a mount command in /etc/rc.d/rc.local
> that could simply fail if the device isn't connected.
>
Yes, that was an attempt to avoid the hang on boot, what I really need is
more complex, and I may have to put it in rc.local to make it work, although
I will test on Fedora using the nofail option. As I look at the RHEL world,
I expect RHEL7 to be along before too long. Perhaps that would satisfy all
requirements.
It depends on what the 'nofail' option does if the UUID is present but
doesn't pass fsck, is it reported and ignored or does it hang the boot?
I see Centos-6.3 'mount' has already 'nofail' option, then it should
perhaps be in equivalent RHEL (and work with fstab fs_passno=2 as You
want).
4101
days inactive
4105
days old
9 comments
6 participants
participants (6)
-
Bill Davidsen -
Development discussions related to Fedora -
Franta Hanzlík -
Ian Pilcher -
Joe Zeff -
Tom Horsley