Mail Archive Search: <+subject:/^(?:^\s*(re|sv|fwd|fw)[\[\]\d]*[:>-]+\s*)*working\s+on\s+extent\s+locks\s+for\s+i

Results:

References: [ +subject:/^(?:^\s*(re|sv|fwd|fw)[\[\]\d]*[:>-]+\s*)*working\s+on\s+extent\s+locks\s+for\s+i_mutex\s*$/: 9 ]

Total 9 documents matching your query.

1. Re: working on extent locks for i_mutex (score: 1): Author: Dave Chinner <david@xxxxxxxxxxxxx>; Date: Fri, 13 Jan 2012 15:34:11 +1100; What locking API are you looking at? If you are looking at an something like: read_range_{try}lock(lock, off, len) read_range_unlock(lock, off, len) write_range_{try}lock(lock, off, len) write_range_; /archives/xfs/2012-01/msg00191.html (8,292 bytes)
2. Re: working on extent locks for i_mutex (score: 1): Author: Tao Ma <tm@xxxxxx>; Date: Fri, 13 Jan 2012 15:14:51 +0800; Interesting, so xfs already have these range lock, right? If yes, any possibility that the code can be reused in ext4 since we have the same thing in mind but don't have any resource to work on it by; /archives/xfs/2012-01/msg00193.html (9,940 bytes)
3. Re: working on extent locks for i_mutex (score: 1): Author: Dave Chinner <david@xxxxxxxxxxxxx>; Date: Fri, 13 Jan 2012 22:52:32 +1100; No, it doesn't have range locks. If has separate locks for IO exclusion vs metadata modification (i_iolock vs i_ilock). Both are rwsems, the ilock nests inside and protects the extent list and other; /archives/xfs/2012-01/msg00196.html (10,478 bytes)
4. Re: working on extent locks for i_mutex (score: 1): Author: Tao Ma <tm@xxxxxx>; Date: Fri, 13 Jan 2012 19:57:21 +0800; OK, I see. Thanks for the information. fair enough. :) Thanks Tao; /archives/xfs/2012-01/msg00197.html (11,373 bytes)
5. Re: working on extent locks for i_mutex (score: 1): Author: Allison Henderson <achender@xxxxxxxxxxxxxxxxxx>; Date: Fri, 13 Jan 2012 13:50:52 -0700; I know this is an old topic, but I am poking it again because I've had some work items wrap up, and Im planning on picking up on this one again. I am thinking about implementing extent locks to repla; /archives/xfs/2012-01/msg00207.html (9,711 bytes)
6. Re: working on extent locks for i_mutex (score: 1): Author: Dave Chinner <david@xxxxxxxxxxxxx>; Date: Mon, 16 Jan 2012 10:57:47 +1100; Yes, that's what I'm suggesting. Not so much a vfs layer function, but a library (range locks could be useful outside filesystems) so locating it in lib/ was what I was thinking.... Cheers, Dave. --; /archives/xfs/2011-10/msg00573.html (9,462 bytes)
7. Re: working on extent locks for i_mutex (score: 1): Author: Zheng Liu <gnehzuil.liu@xxxxxxxxx>; Date: Wed, 18 Jan 2012 20:02:23 +0800; Hi Allison, For this project, do you have a schedule? Would you like to share to me? This lock contention heavily impacts the performance of direct IO in our production environment. So we hope to imp; /archives/xfs/2012-01/msg00244.html (14,884 bytes)
8. Re: working on extent locks for i_mutex (score: 1): Author: Frank Mayhar <fmayhar@xxxxxxxxxx>; Date: Thu, 19 Jan 2012 13:16:10 -0800; For the record, I have a patchset that, while not affecting i_mutex (or locking in general), does allow AIO append writes to actually be done asynchronously. (Currently they're forced to be done sync; /archives/xfs/2012-01/msg00260.html (11,113 bytes)
9. Re: working on extent locks for i_mutex (score: 1): Author: Zheng Liu <gnehzuil.liu@xxxxxxxxx>; Date: Fri, 20 Jan 2012 10:26:49 +0800; Interesting. I think it might help us to improve this issue. So could you please post your test case and result in detail? Thank you. :-) Regards, Zheng; /archives/xfs/2012-01/msg00261.html (12,745 bytes)

Current List: 1 - 9
Page: [1]