From: Marcus Osdoba <marcus.osdoba@googlemail.com>
To: Dave Chinner <david@fromorbit.com>
Cc: Eric Sandeen <sandeen@sandeen.net>, xfs@oss.sgi.com
Subject: Re: xfs on armv5 still with erroneous log in kernel 2.6.35.4
Date: Wed, 08 Sep 2010 20:36:03 +0200 [thread overview]
Message-ID: <4C87D793.8000103@googlemail.com> (raw)
In-Reply-To: <20100908074357.GS705@dastard>
Am 08.09.2010 09:43, schrieb Dave Chinner:
>
> FWIW, please copy the exact commands and errors from your terminal -
> paraphrasing them like this does not help me underѕtand exactly what
> is happening...
Hi Dave,
I'm very sorry for annoying you. Please excuse this.
You asked me to copy the exact commands from the terminal. I did that
despite the fact, that I replaced "cp /bin/* /data" with "cp something
on it". All other commands are 100% the same in exactly the given order
in the former mail.
Furthermore you asked me to give the output of xfs_printlog with and
without option -t. I gave that output in the last mail, too.
Please take my apologies and note the workflow I have tested:
>mount -t xfs /dev/sda1 /data
>cp /bin/sh /data
>sync
>umount /data
>xfs_printlog /dev/sda1
#no ERROR entry visible
>mount -t xfs /dev/sda1 /data
#re mounting works fine, no problems!,
#so I thought running a sync before the umount would solve my erroneous
log problem on ARM devices
# The following command chain trys to reproduce the error
>mount -t xfs /dev/sda1 /data
>cp /bin/* /data
>sync
Device or resource busy.
>sync
>umount /data
>xfs_printlog /dev/sda1
#includes an ERROR entry at the end, see last mail
The output of dmesg after trying to mount a partition on which I wrote
some files before,
I gave in the very first mail:
"
SGI XFS with ACLs, security attributes, large block/inode numbers, no
debug enabled
SGI XFS Quota Management subsystem
XFS mounting filesystem sda1
Starting XFS recovery on filesystem: sda1 (logdev: internal)
XFS: xlog_recover_process_data: bad clientid
XFS: log mount/recovery failed: error 5
XFS: log mount failed
"
My expectations:
- sync should never be mandatory before unmounting to keep the FS clean
(any FS)
- umount should never break the log of the FS
Facts:
Mounting the XFS-Parttition, writing some data on it and unmounting
results in an erroneous log which forces a xfs_repair -L on the next mount.
(This I do not expect either...)
I do not know which debug procedures are useful and would give you some
useful output. Sorry about this.
After summing up the content I gave in the mailchain, please let me
know, if solving this issue has any chance of success.
Thanks and kind regards,
Marcus
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next prev parent reply other threads:[~2010-09-08 18:35 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-09-05 8:52 xfs on armv5 still with erroneous log in kernel 2.6.35.4 Marcus Osdoba
2010-09-06 0:52 ` Dave Chinner
2010-09-06 3:24 ` Eric Sandeen
2010-09-06 18:37 ` Marcus Osdoba
2010-09-07 6:03 ` Dave Chinner
2010-09-07 21:55 ` Marcus Osdoba
2010-09-08 7:43 ` Dave Chinner
2010-09-08 18:36 ` Marcus Osdoba [this message]
2010-09-09 6:45 ` Dave Chinner
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4C87D793.8000103@googlemail.com \
--to=marcus.osdoba@googlemail.com \
--cc=david@fromorbit.com \
--cc=sandeen@sandeen.net \
--cc=xfs@oss.sgi.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox