xfs
[Top] [All Lists]

Re: XFS Preallocation

To: Jef Fox <jef.fox@xxxxxxxxxx>
Subject: Re: XFS Preallocation
From: Dave Chinner <david@xxxxxxxxxxxxx>
Date: Sat, 29 Jan 2011 11:17:00 +1100
Cc: xfs@xxxxxxxxxxx
In-reply-to: <155CAEA5D902E7429569DD197567724A01534D60@xxxxxxxxxxxxxxxxxxx>
References: <155CAEA5D902E7429569DD197567724A01534D42@xxxxxxxxxxxxxxxxxxx> <20110128045205.GR21311@dastard> <155CAEA5D902E7429569DD197567724A01534D60@xxxxxxxxxxxxxxxxxxx>
User-agent: Mutt/1.5.20 (2009-06-14)
On Fri, Jan 28, 2011 at 10:33:03AM -0700, Jef Fox wrote:
> I guess, disregard my previous message.  After some further testing of
> examining the hard disk blocks, we see what you are saying - the file is
> presented at 0s to the user even if the blocks are changed on the hard
> disk.  So, we will always see 0s until we write to the extent.
> 
> So, I think our only question now is if there is a way to force the
> extents to be marked as allocated without writing all of the data?  That
> is, is there a fast way to lay down a file(s) of 1G size without
> actually writing 1G of info.

Preallocation is the only option. Allowing preallocation without
marking extents as unwritten opens a massive security hole (i.e.
exposes stale data) so I say no to any request for addition of such
functionality (and have for years).

You've already demonstrated the workaround you can apply to the
problem for your very specialised application - when you put the
disk back into the original machine you can read the disk blocks
directly to get the data. i.e. use fiemap to map the location of the
file on disk and then read the data directly from the block device
underneath the filesystem...

Cheers,

Dave.
-- 
Dave Chinner
david@xxxxxxxxxxxxx

<Prev in Thread] Current Thread [Next in Thread>