Search String: Display: Description: Sort:

Results:

References: [ +subject:/^(?:^\s*(re|sv|fwd|fw)[\[\]\d]*[:>-]+\s*)*SEEK_DATA\/SEEK_HOLE\s+support\s*$/: 19 ]

Total 19 documents matching your query.

1. SEEK_DATA/SEEK_HOLE support (score: 1)
Author: Jeff Liu <jeff.liu@xxxxxxxxxx>
Date: Sun, 02 Oct 2011 23:04:31 +0800
Dear developer, Does anyone already worked on SEEK_DATA/SEEK_HOLE for XFS? I'd like to implement it if not. :) Thanks, -Jeff
/archives/xfs/2011-10/msg00003.html (6,802 bytes)

2. Re: SEEK_DATA/SEEK_HOLE support (score: 1)
Author: Christoph Hellwig <hch@xxxxxxxxxxxxx>
Date: Sun, 2 Oct 2011 11:42:59 -0400
Dave mentioned he had a basic implementation, he might have some code that you can improve on. Did we get consensus about the the semantics of them for unwritten extents? If we want them to be exact
/archives/xfs/2011-10/msg00004.html (8,945 bytes)

3. Re: SEEK_DATA/SEEK_HOLE support (score: 1)
Author: Jeff Liu <jeff.liu@xxxxxxxxxx>
Date: Mon, 03 Oct 2011 00:06:37 +0800
Hi Christoph, IMHO, to avoid data loss in some user application like cp(1), for unwritten extents, we always need to check the pages status. Just as you mentioned above, return the map offset if page
/archives/xfs/2011-10/msg00005.html (10,036 bytes)

4. Re: SEEK_DATA/SEEK_HOLE support (score: 1)
Author: Christoph Hellwig <hch@xxxxxxxxxxxxx>
Date: Sun, 2 Oct 2011 13:59:02 -0400
I'd suggest to first implement the simple versions I schemed below, which would treat unwritten extents as data. That is sub-optimal, but a) safe and b) easy to implement. The second step would be to
/archives/xfs/2011-10/msg00006.html (8,335 bytes)

5. Re: SEEK_DATA/SEEK_HOLE support (score: 1)
Author: Andi Kleen <andi@xxxxxxxxxxxxxx>
Date: Sun, 02 Oct 2011 12:11:07 -0700
Also when you do it please make sure you don't break unlocked lseek() The patches for that are in Al's queue. Only take the lock for SEEK_HOLE/DATA, but not for the other operations. Use the new help
/archives/xfs/2011-10/msg00007.html (7,991 bytes)

6. Re: SEEK_DATA/SEEK_HOLE support (score: 1)
Author: Jeff Liu <jeff.liu@xxxxxxxxxx>
Date: Mon, 03 Oct 2011 12:04:11 +0800
So I'll wait for Dave's patch become ready, and then continue to improve it if necessary. In the meantime, I'll try to figure out how to add a helper which can be shared by all file systems for UNWRI
/archives/xfs/2011-10/msg00008.html (8,942 bytes)

7. Re: SEEK_DATA/SEEK_HOLE support (score: 1)
Author: Dave Chinner <david@xxxxxxxxxxxxx>
Date: Tue, 4 Oct 2011 10:43:05 +1100
The lookup is pretty simple - if there's cached data over the unwritten range, then I'm considering it a data range. If there's no cached data over the unwritten extent, it's a hole. That makes the l
/archives/xfs/2011-10/msg00027.html (10,182 bytes)

8. Re: SEEK_DATA/SEEK_HOLE support (score: 1)
Author: Christoph Hellwig <hch@xxxxxxxxxxxxx>
Date: Tue, 4 Oct 2011 09:02:08 -0400
Actually pretty similar code will work just fine if you passt the start + len of the extents in (which we got from looking it up fs-specificly): Note that we have to look for both dirty and writeback
/archives/xfs/2011-10/msg00028.html (9,906 bytes)

9. Re: SEEK_DATA/SEEK_HOLE support (score: 1)
Author: Dave Chinner <david@xxxxxxxxxxxxx>
Date: Wed, 5 Oct 2011 15:36:59 +1100
That will only work if you can prevent concurrent unwritten extent conversion from happening while we do the separate tag lookups on the range because it requires two radix tree tag lookups rather th
/archives/xfs/2011-10/msg00037.html (11,438 bytes)

10. Re: SEEK_DATA/SEEK_HOLE support (score: 1)
Author: Jeff Liu <jeff.liu@xxxxxxxxxx>
Date: Tue, 4 Oct 2011 22:32:11 -0700 (PDT)
utilites does not need to perform read/write for an unwritten extents without dirty or writeback pages, instead, just call lseek(2) to treat it as hole. The issue is, is it worth to do that? i.e, exc
/archives/xfs/2011-10/msg00038.html (13,345 bytes)

11. Re: SEEK_DATA/SEEK_HOLE support (score: 1)
Author: Michael Monnerie <michael.monnerie@xxxxxxxxxxxxxxxxxxx>
Date: Wed, 5 Oct 2011 09:34:26 +0200
I'd like to understand why it's important to care about locking here. As I understand it, SEEK_* is used for example to copy a file efficiently. If that is performed on a file that is currently being
/archives/xfs/2011-10/msg00039.html (11,606 bytes)

12. Re: SEEK_DATA/SEEK_HOLE support (score: 1)
Author: Dave Chinner <david@xxxxxxxxxxxxx>
Date: Wed, 5 Oct 2011 20:23:29 +1100
Yes, that's a use case for SEEK_HOLE/DATA, but that has nothing to do with the filesystem implementation issues involved with page state changes. What we nee dto avoid is a page state change from cau
/archives/xfs/2011-10/msg00040.html (14,233 bytes)

13. Re: SEEK_DATA/SEEK_HOLE support (score: 1)
Author: Dave Chinner <david@xxxxxxxxxxxxx>
Date: Wed, 5 Oct 2011 20:36:15 +1100
The problem is that copying a file with dirty data hot in the cache concurrently when writeback to that file is occurring. The application is not modifying the file, and the state changes that could
/archives/xfs/2011-10/msg00041.html (11,833 bytes)

14. Re: SEEK_DATA/SEEK_HOLE support (score: 1)
Author: Jeff Liu <jeff.liu@xxxxxxxxxx>
Date: Wed, 05 Oct 2011 21:56:08 +0800
Thanks for your clarification! Now I understood your option. Indeed, if the utility treat unwritten extents as data, we do not need to worry about the pages state conversion procedures. Otherwise, we
/archives/xfs/2011-10/msg00048.html (15,643 bytes)

15. Re: SEEK_DATA/SEEK_HOLE support (score: 1)
Author: Michael Monnerie <michael.monnerie@xxxxxxxxxxxxxxxxxxx>
Date: Wed, 5 Oct 2011 20:22:18 +0200
Thanks for the thorough explanation. So it's a problem when a file has recently been modified and not yet been written back to disk. Would it be worth to force a flush to disk before SEEK_* operation
/archives/xfs/2011-10/msg00050.html (9,835 bytes)

16. Re: SEEK_DATA/SEEK_HOLE support (score: 1)
Author: Dave Chinner <david@xxxxxxxxxxxxx>
Date: Thu, 6 Oct 2011 11:32:34 +1100
The problem is that application does not know whether fsync is needed or not, so it would have to do that unconditionally for every file it was copying. That has potential for quite severe, unexpecte
/archives/xfs/2011-10/msg00058.html (9,974 bytes)

17. Re: SEEK_DATA/SEEK_HOLE support (score: 1)
Author: Christoph Hellwig <hch@xxxxxxxxxxxxx>
Date: Mon, 14 Nov 2011 05:24:44 -0500
Just curious: did you start looking into implementing SEEK_DATA/SEEK_HOLE support?
/archives/xfs/2011-11/msg00264.html (6,685 bytes)

18. Re: SEEK_DATA/SEEK_HOLE support (score: 1)
Author: Jeff Liu <jeff.liu@xxxxxxxxxx>
Date: Mon, 14 Nov 2011 20:47:36 +0800
Hi Christoph, I have misunderstood your previous response: "Dave mentioned he had a basic implementation, he might have some code that you can improve on. So I am still waiting that now. But actually
/archives/xfs/2011-11/msg00269.html (8,266 bytes)

19. Re: SEEK_DATA/SEEK_HOLE support (score: 1)
Author: Christoph Hellwig <hch@xxxxxxxxxxxxx>
Date: Mon, 14 Nov 2011 07:50:44 -0500
He mentioned that, but given that there was no folloup with code I wouldn't expect it to appear anymore. Thanks a lot!
/archives/xfs/2011-11/msg00270.html (8,215 bytes)


This search system is powered by Namazu