[GRLUG] weird mount thing

[Michael Mol]

On Mon, Mar 7, 2011 at 10:51 AM, John-Thomas Richards <jtr at jrichards.org> wrote:
> On Mon, Mar 07, 2011 at 10:28:29AM -0500, Michael Mol wrote:
>> On Mon, Mar 7, 2011 at 10:18 AM, John-Thomas Richards <jtr at jrichards.org> wrote:
>> > I attempted to unmount something earlier and it wouldn't unmount.  When
>> > I did a `mount' I received this along with the usual stuff I expect to
>> > see:
>> >
>> > /dev/sda6 on /home type ext3 (rw,commit=0,commit=600,commit=0,commit=600,commit=0,commit=600,commit=0,commit=600,commit=0,commit=600,commit=0,commit=600,commit=0,commit=600,commit=0,commit=600,commit=0,commit=600,commit=0,commit=600,commit=0,commit=600,commit=0,commit=600,commit=0,commit=600,commit=0,commit=600,commit=0,commit=600,commit=0,commit=0,commit=0,commit=600,commit=0,commit=600,commit=0,commit=600.......
>> >
>> > The `commit=0,commit=600' repeats many times.  I've never seen this
>> > before.  Any ideas why I'm getting this?  None of the other mount points
>> > do this (well, / shows `/dev/sda5 on / type ext3
>> > (rw,errors=remount-ro,commit=0)').  Should I be concerned about
>> > something?
>>
>> That's clearly a bug somewhere. Even if there's a hardware issue
>> somewhere, something would likely need to be screwed up in code for
>> that kind of iterative listing error. You should report it to your
>> distro's bugtracker for the package owning mount/umount.
>>
>> I'd include:
>>
>> * normal and 'strace' output for:
>> ** mount
>> ** umount /home
>> * any seemingly-relevant lines in syslog in proximity to when that
>> mount point was mounted, and  the same in proximity to when you
>> attempted to unmount
>> * The output of 'file -s /dev/sda6'.
>
> root at rondo:/home/jtr# file -s /dev/sda6
> /dev/sda6: Linux rev 1.0 ext3 filesystem data,\
> UUID=991fdaf9-bdc1-4ef4-b00e-8627345bfdbe (needs journal recovery) (large files)
>
> `needs journal recovery' sounds ominous.

No, it just means you looked at it while the filesystem is mounted.
That flag is _always_ set when the filesystem is mounted, and only
unset when it's cleanly unmounted.

I was mistaken, though; 'file -s' isn't going to be particularly
useful here, 'tune2fs -l /dev/sda6' will be.

>
>> Finally, I'd try running fsck on the /dev/sda6, possibly from a
>> different machine, after running smart tests on the drive, and include
>> the output from those.
>
> It's amazing how a quick answer from Mike can usher in a whole new sense
> of humility.  :-)  After 14 years with Linux I know nothing.

Hey, no fret; I write custom software (on Windows) for a living, and I
try to base ideas on educated guesses of how things are likely to be
written. Seeing something like repeated, conflicting symbols in a
listing (commit=0,commit=600,commit=0,commit=600) screams "someone
didn't validate something" to me.

I don't know much at all about how mount works, or how it interacts
with the kernel. 'strace' is like a process-specific 'procmon' for
Linux; it traces out an app's system calls.

The developers maintaining 'mount' will benefit from seeing the
interaction of the program with the kernel. The syslog entries should
show any oopses, the output of any the fsck and mount operations, and
any warnings about hardware behavior. That'll come in handy if the bug
report gets bumped over to a different package like e2fsck or the
kernel. (The one thing I _hate_ about filing bug reports is the gaff I
get for filing it against the wrong package. Most package bug trackers
have a massive SEP field in place, IME, and it can make it incredibly
hard to get bugs fuxed.)

-- 
:wq

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.