Nathan Scott wrote:
Hi Wayne,
Hello Nathan,
On Tue, 2007-10-02 at 10:38 -0700, Wayne Tucker wrote:
fsck.xfs doesn't check to see if the device it is asked to check
exists. This can result in a system booting with an incomplete set of
filesystem mounts. The included patch works for me, although I only
have a limited number of systems on which to test it.
Hmm, OK - seems safe enough I guess. It'd be nice to understand
the root cause here a bit - is the problem that we dont attempt to
access /dev/foo at all, so udev doesn't see any requests for that
device and doesnt create the device node? Then later when we try
to mount, the mount userspace code gets ENODEV? If so, I wonder
why the mount doesn't populate the device nodes on its access?
My knowledge of udev is pretty limited, so I'm not sure if that would
come into play at all.
The situation I ran into is when the device that is supposed to contain
the xfs filesystem is missing. fsck.xfs doesn't tell checkfs.sh that
there's a problem, and mountall.sh gladly assumes that checkfs.sh did
all of the legwork.
This bug might be more appropriately applied to the initscripts package,
but I decided to file it here since:
1.) this was an easier fix
2.) in the same scenario, fsck.(ext(2|3)|minix|cramfs|jfs) return errors
3.) this was a much easier fix. :)
In my case, the missing devices are being caused by intermittent XENBUS
timeouts. The the VM boots but doesn't realize that /var/log isn't
mounted. There's an underlying issue that needs to be resolved there,
but the same problem could happen on normal machines in the event that a
physical device is dead.
Also, the NFS fsck program is also a shell script, I wonder if it
might suffer similar issues and need a similar patch? Possibly not
since theres no local device involved there.
It looks like fsck.nfs may just be a kludge for people that specify a
pass other than 0 on nfs mounts. mountnfs.sh is smarter than
mountlocal.sh and doesn't seem to be dependent on fsck for anything.
I'll send the patch upstream and solicit their thoughts as well.
Thanks for your time and consideration.
- Wayne
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
