Mail Archive Search: <+subject:/^(?:^\s*(re|sv|fwd|fw)[\[\]\d]*[:>-]+\s*)*\[PATCH\]\s+xfs\:\s+Avoid\s+pathological\s+backwards\s+allocation\s*$/>

Results:

References: [ +subject:/^(?:^\s*(re|sv|fwd|fw)[\[\]\d]*[:>-]+\s*)*\[PATCH\]\s+xfs\:\s+Avoid\s+pathological\s+backwards\s+allocation\s*$/: 3 ]

Total 3 documents matching your query.

1. [PATCH] xfs: Avoid pathological backwards allocation (score: 1): Author: Jan Kara <jack@xxxxxxx>; Date: Thu, 11 Apr 2013 13:44:51 +0200; Writing a large file using direct IO in 16 MB chunks sometimes results in a pathological allocation pattern where 16 MB chunks of large free extent are allocated to a file in a reversed order. So ext; /archives/xfs/2013-04/msg00234.html (12,769 bytes)
2. Re: [PATCH] xfs: Avoid pathological backwards allocation (score: 1): Author: Dave Chinner <david@xxxxxxxxxxxxx>; Date: Thu, 11 Apr 2013 22:50:03 +1000; I think this probably needs a little more detail as to why we we do this for user data. i.e. to carve from the front edge of the free extent to allow for contiguous allocation from the remaining free; /archives/xfs/2013-04/msg00235.html (13,987 bytes)
3. Re: [PATCH] xfs: Avoid pathological backwards allocation (score: 1): Author: Jan Kara <jack@xxxxxxx>; Date: Thu, 11 Apr 2013 22:08:17 +0200; OK, added. I agree. I expanded the comment a bit. Yes, I came to the same conclusion when I was thinking about this when writing the patch. Thanks. I'll send v2 with the updates you suggested shortly; /archives/xfs/2013-04/msg00245.html (15,938 bytes)

Current List: 1 - 3
Page: [1]