From: Dave Chinner <david@fromorbit.com>
To: Eric Sandeen <sandeen@sandeen.net>
Cc: xfs@oss.sgi.com
Subject: Re: file preallocation without unwritten flag being set
Date: Thu, 14 May 2009 10:34:22 +1000 [thread overview]
Message-ID: <20090514003422.GM16929@discord.disaster> (raw)
In-Reply-To: <4A0B6325.8000706@sandeen.net>
On Wed, May 13, 2009 at 07:17:41PM -0500, Eric Sandeen wrote:
> p v wrote:
> > with the default mkfs and mount options. I created the fs, cleared
> > extflg from the superblocks and run xfs_io to resvsp the space. Then
> > I run truncate and truncate decided to initialize the extents to zero
> > and since it's 10TB it's going to take a while (can't reset as it's a
> > remote machine and xfs_io is looping in the kernel ...). It didn't do
......
>
> try truncate then resvsp; TBH not sure why it should matter though :)
Uninitialised extents beyond EOF get zeroed when EOF is moved.
if you set the set before preallocation, then there are no extents
to zero. FWIW, if they have the unwritten flag, this zeroing does not occur.
> > I am a little bit lost about the comment regarding the page caches. I
> > unmounted the filesystem before running xfs_db. Shouldn't that flush
> > pages, buffers, ...? I assume that xfs_db goes directly to the device
> > so if the fs was unmounted then the device should be up to date?
>
> The device is uptodate but the bdev address space may not be.
>
> Unmounting will flush the filesytem address space, but not the block
> device address space.
Not exactly the problem, though. XFS opens it's own device address space
when mounting - not the address space you get by opening /dev/sdX.
xfs_db uses the address space associated with /dev/sdX. hence
if you do:
# xfs_db /dev/sdc
....
# mount /dev/sdc
<do some changes>
# unmount /dev/sdc
# xfs_db /dev/sdc
The second invocation of xfs_db will not see any of the changes that
occured to the filesystem because it will read from the buffers
cached on /dev/sdc during the first invocation.
This is the same problem Grub has....
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next prev parent reply other threads:[~2009-05-14 0:34 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-05-12 23:02 file preallocation without unwritten flag being set p v
2009-05-13 0:04 ` Eric Sandeen
2009-05-13 4:34 ` p v
2009-05-13 5:08 ` Eric Sandeen
2009-05-13 21:05 ` p v
2009-05-13 21:48 ` Eric Sandeen
2009-05-13 22:28 ` Dave Chinner
2009-05-13 23:51 ` p v
2009-05-14 0:17 ` Eric Sandeen
2009-05-14 0:34 ` Dave Chinner [this message]
2009-05-14 0:41 ` Eric Sandeen
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=20090514003422.GM16929@discord.disaster \
--to=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