From: David Chinner <dgc@sgi.com>
To: Jan Derfinak <ja@mail.upjs.sk>
Cc: David Chinner <dgc@sgi.com>, xfs@oss.sgi.com
Subject: Re: Differences in mkfs.xfs and xfs_info output.
Date: Mon, 18 Feb 2008 10:06:45 +1100 [thread overview]
Message-ID: <20080217230645.GY155407@sgi.com> (raw)
In-Reply-To: <Pine.LNX.4.63.0802162319300.6528@alienAngel.home.sk>
On Sat, Feb 16, 2008 at 11:41:42PM +0100, Jan Derfinak wrote:
> On Sat, 16 Feb 2008, David Chinner wrote:
>
> > had time. The patch below should fix the problem - mkfs.xfs is writing
> > the features2 field to the wrong location in the superblock, and
> > this patch detects and corrects it. You'll probably see the output:
>
> I would like to ask if correcting the feature2 field can lead to this
> message?:
> # xfs_check /dev/system/mnt
> sb_fdblocks 190009, counted 191033
> sb_fdblocks 190009, aggregate AGF count 191033
Lazy superblock counters mean that the superblock counters
are not kept exactly up to date at all times and hence this
can happen if the filesystem was not shut down cleanly. however,
when you remount the filesystem, it should recover all of the
correct values due to redundant information in the AGF and AGI
headers (that's the "aggregate AGF count" above). In the case
of a clean shutdown, however, they should be up to date.
Is this reproducable with simple tests? e.g. mkfs, mount, unmount
check? or doing some simple things like creating some files
with dd and rm'ing a subset of the files before unmounting?
I've run some simple tests this morning that do this, and I
don't see any issues. I'd like to confirm that simple cases
are working correctly on your test setup first...
Cheers,
Dave.
--
Dave Chinner
Principal Engineer
SGI Australian Software Group
next prev parent reply other threads:[~2008-02-17 23:06 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-02-16 1:34 Differences in mkfs.xfs and xfs_info output Jan Derfinak
2008-02-16 4:10 ` Eric Sandeen
2008-02-16 4:33 ` Eric Sandeen
2008-02-16 4:36 ` Eric Sandeen
2008-02-16 4:41 ` Eric Sandeen
2008-02-16 7:40 ` David Chinner
2008-02-16 21:49 ` Jan Derfinak
2008-02-16 22:41 ` Jan Derfinak
2008-02-17 13:41 ` Jan Derfinak
2008-02-17 23:06 ` David Chinner [this message]
2008-02-18 0:12 ` Jan Derfinak
2008-02-19 0:04 ` Jan Derfinak
2008-02-19 0:20 ` David Chinner
2008-02-19 1:20 ` Jan Derfinak
2008-02-19 1:46 ` David Chinner
2008-02-19 2:10 ` Jan Derfinak
2008-02-19 14:05 ` Jan Derfinak
2008-02-20 5:42 ` David Chinner
2008-03-16 22:44 ` Jan Derfinak
2008-02-18 0:17 ` Jan Derfinak
2008-02-18 2:07 ` David Chinner
2008-02-18 6:56 ` ja
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=20080217230645.GY155407@sgi.com \
--to=dgc@sgi.com \
--cc=ja@mail.upjs.sk \
--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