| To: | Bhagi rathi <jahnu77@xxxxxxxxx> |
|---|---|
| Subject: | Re: TAKE 972756 - Implement fallocate. |
| From: | Eric Sandeen <sandeen@xxxxxxxxxxx> |
| Date: | Tue, 06 Nov 2007 13:04:05 -0600 |
| Cc: | David Chinner <dgc@xxxxxxx>, xfs@xxxxxxxxxxx |
| In-reply-to: | <cc7060690711060927n1ea8a489n9f02029a11b73b00@mail.gmail.com> |
| References: | <20071102024314.9BF3458C38F7@chook.melbourne.sgi.com> <cc7060690711051042h5c39c540mf60f95e2f67c7bd7@mail.gmail.com> <20071106001223.GY66820511@sgi.com> <cc7060690711060927n1ea8a489n9f02029a11b73b00@mail.gmail.com> |
| Sender: | xfs-bounce@xxxxxxxxxxx |
| User-agent: | Thunderbird 1.5.0.12 (X11/20070530) |
Bhagi rathi wrote: > File is of size 1k. A 4k block is allocated as file-system block size is > 4k. > Preallocation happened from 1k to 256k. Now, it looks to me that we have > un-written extents from 4k to 256k. There is no guarantee that data from 1k > to 4k is all zero'es. Fallocate is updating size. Hence on subsequent read, > we can get garbage from 1k to 4k and all zero'es from 4k to 256k You've tested this and found it to be true? -Eric > Is the expectation here is application should take the responsibility of > zero'ing > data? I still need to through fallocate requirements. |
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| ||
| Previous by Date: | Re: 7Tb XFS partition lost on reboot, Eric Sandeen |
|---|---|
| Next by Date: | Re: writeout stalls in current -git, Peter Zijlstra |
| Previous by Thread: | Re: TAKE 972756 - Implement fallocate., Bhagi rathi |
| Next by Thread: | Re: TAKE 972756 - Implement fallocate., David Chinner |
| Indexes: | [Date] [Thread] [Top] [All Lists] |