[Lustre-devel] Commit on share
adilger at sun.com
Tue Jun 3 11:41:51 PDT 2008
On Jun 01, 2008 11:03 +0400, Mike Pershin wrote:
> On Sat, 31 May 2008 06:45:24 +0400, Andreas Dilger <adilger at sun.com> wrote:
>> RepACK is currently needed for recovery. I don't think it is a false
>> conflict in most cases, though I agree in some cases it is. If MDS
>> thread is only e.g. passing through a directory to do some operation
>> in a previously-existing subdirectory, or wants to stat a file that
>> existed before the conflicting lock was taken then this is a false
> RepACK is not needed for recovery if COS is enabled, because COS will sync
> the share cases so there is no need to be sure that client got reply and
> will do replay as there are no dependent replays on it.
> Also the cases are creations from different clients or unlinks (operations
> of same type). They are not dependent actually, the only dependency here
> may be create vs unlink or unlink vs create. Currently such cases are not
> distinguished and we block access for any operation from different client.
In 2.0 with per-name-hash locking we will remove almost all such false
dependencies, so I don't know whether the intermediate optimization is
worthwhile or not.
>> Also, isn't it enough to store a single such item per object directly
>> on the object? Once we know there is ANY such conflict that is enough
>> to invoke COS. For per-object data this can be stored on 1.6 in the
>> i_filterdata structure that we can attach onto every server inode.
> It is per-object, yes. And this is very valuable advice about i_filterdata.
> I thought we have no access to inode_info from upper level at server side.
> This will reduce need for hash at all and simplify things a lot.
Well, in 1.6/1.8 the layering isn't so strict, and in HEAD the problem
goes away because of per-object data/locking. I also don't think Alex's
worry about the i_filterdata lifetime is warranted. If the inode is
being evicted from cache, then it surely must have been written to disk,
so there is no need to cache the last-modified data at all as COS is
not needed anymore.
Sr. Staff Engineer, Lustre Group
Sun Microsystems of Canada, Inc.
More information about the lustre-devel