xfs
[Top] [All Lists]

Re: TAKE 972756 - Implement fallocate.

To: "Bhagi rathi" <jahnu77@xxxxxxxxx>
Subject: Re: TAKE 972756 - Implement fallocate.
From: nscott@xxxxxxxxxx
Date: Wed, 7 Nov 2007 20:35:21 +1100 (EST)
Cc: "David Chinner" <dgc@xxxxxxx>, xfs@xxxxxxxxxxx
Importance: Normal
In-reply-to: <cc7060690711062142h3668e831o8fc49bdb5a1615bf@xxxxxxxxxxxxxx>
References: <20071102024314.9BF3458C38F7@xxxxxxxxxxxxxxxxxxxxxxx> <cc7060690711051042h5c39c540mf60f95e2f67c7bd7@xxxxxxxxxxxxxx> <20071106001223.GY66820511@xxxxxxx> <cc7060690711060927n1ea8a489n9f02029a11b73b00@xxxxxxxxxxxxxx> <20071106204100.GW995458@xxxxxxx> <1194388733.3862.206.camel@xxxxxxxxxxxxxx> <cc7060690711062142h3668e831o8fc49bdb5a1615bf@xxxxxxxxxxxxxx>
Sender: xfs-bounce@xxxxxxxxxxx
User-agent: SquirrelMail/1.4.8-4.el4.centos
> Since size log change and data I/O are not binded, it is always possible
> that size can reach to the
> disk before I/O reaching to the disk.

Not clear what that has to do with whether partial blocks are zeroed or not?
Can you give a specific series of steps that would demonstrate a problem?
(preferably with a test case)

> Also, the other problem is because
> of
> speculative allocation.
> A write-back allocation can leady to allocation of delayed extents into
> real
> and gets pruned only
> close of the file.
> Before that, we get fallocate, it allocates the exents,
> but the extents residing
> because of delayed allocation write-back will not have zero'ed content.

Again, I think a test case demonstrating the problem would go a long way
to helping explain the issue.

The preallocation code and ioctl interface have been in XFS forever on
Linux - are you reporting problems you've actually observed here, or
are these rather "potential issues" that you foresee from code analysis?

cheers.

--
Nathan


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