[Ocfs2-devel] [patch 09/11] ocfs2: llseek requires ocfs2 inode lock for the file in SEEK_END
Jensen
shencanquan at huawei.com
Mon Feb 10 19:35:18 PST 2014
On 2014/2/11 7:57, Andrew Morton wrote:
> On Mon, 10 Feb 2014 16:51:32 +0800 Jensen <shencanquan at huawei.com> wrote:
>
>>>> ocfs2 is a cluster file system. as like read/write/open/rmdir/unlink interface which think of cluster-aware. I think the seek interface need
>>>> cluster-aware. May be it has the performance impact. but it's correctness is more important than performance.
>>> That doesn't mean we can't or shouldn't quantify the performance impact of your patch.
>>>
>>> Please help us measure what the end-user impact of this change will be.
>>> --Mark
>> test result: 1000000 times lseek call;
>> index lseek with inode lock (unit:us) lseek without inode lock (unit:us)
>> 1 1168162 555383
>> 2 1168011 549504
>> 3 1170538 549396
>> 4 1170375 551685
>> 5 1170444 556719
>> 6 1174364 555307
>> 7 1163294 551552
>> 8 1170080 549350
>> 9 1162464 553700
>> 10 1165441 552594
>>
>> avg 1168317 552519
>>
>> avg with lock - avg without lock = 615798
>> (avg with lock - avg without lock)/1000000=0.615798 us
> hm, what does that actually mean. I guess that to get a feel for the
> impact on real workloads, this latency needs to be compared with the
> time for a small IO on fast hardware.
>
> One could test that by creating a large file then doing lots of
> "lseek(random)+read" operations. Which requires forgetting about
> the existence of pread() ;)
>
> .
because lseek only lock in SEEK_END. so your above mention can't test.
>
More information about the Ocfs2-devel
mailing list