I'm not going to be at Connectathon, but I could call in for a
discussion.=20
-----Original Message-----
From: Benny Halevy [mailto:[email protected]]=20
Sent: Monday, January 15, 2007 3:45 AM
To: Noveck, Dave; Trond Myklebust
Cc: Spencer Shepler; [email protected]; [email protected]
Subject: Re: [nfsv4] RE: Finding hardlinks
How about discussing this topic in the upcoming Connectathon?
Benny
Noveck, Dave wrote:
> For now, I'm not going to address the controversial issues here,=20
> mainly because I haven't decided how I feel about them yet.
>=20
> Whether allowing multiple filehandles per object is a good
> or even reasonably acceptable idea.
>=20
> What the fact that RFC3530 talks about implies about what
> clients should do about the issue.
>=20
> One thing that I hope is not controversial is that the v4.1 spec=20
> should either get rid of this or make it clear and implementable.
> I expect plenty of controversy about which of those to choose, but=20
> hope that there isn't any about the proposition that we have to choose
> one of those two.
>=20
>> SECINFO information is, for instance, given out on a per-filehandle=20
>> basis, does that mean that the server will
> have
>> different security policies?=20
>=20
> Well yes, RFC3530 does say "The new SECINFO operation will allow the=20
> client to determine, on a per filehandle basis", but I think that just
> has to be considered as an error rather than indicating that if you=20
> have two different filehandles for the same object, they can have=20
> different security policies. SECINFO in RFC3530 takes a directory fh=20
> and a name, so if there are multiple filehandles for the object with=20
> that name, there is no way for SECINFO to associate different policies
> with different filehandles. All it has is the name to go by. I think
> this should be corrected to "on a per-object basis" in the new spec no
> matter what we do on other issues.
>=20
> I think the principle here has to be that if we do allow multiple fh's
> to map to the same object, we require that they designate the same=20
> object, and thus it is not allowed for the server to act as if you=20
> have multiple different object with different characteristics.
>=20
> Similarly as to:
>=20
>> In some places, people haven't even started to think about the=20
>> consequences:
>>
>> If GETATTR directed to the two filehandles does not return the
>> fileid attribute for both of the handles, then it cannot be
>> determined whether the two objects are the same. Therefore,
>> operations which depend on that knowledge (e.g., client side data
>> caching) cannot be done reliably.
>=20
> I think they (and maybe "they" includes me, I haven't checked the=20
> history
> here) started to think about them, but went in a bad direction.
>=20
> The implication here that you can have a different set of attributes=20
> supported for the same object based on which filehandle is used to=20
> access the attributes is totally bogus.
>=20
> The definition of supp_attr says "The bit vector which would retrieve=20
> all mandatory and recommended attributes that are supported for this=20
> object. The scope of this attribute applies to all objects with a=20
> matching fsid." So having the same object have different attributes=20
> supported based on the filehandle used or even two objects in the same
> fs having different attributes supported, in particular having fileid=20
> supported for one and not the other just isn't valid.
>=20
>> The fact is that RFC3530 contains masses of rope with which to allow=20
>> server and client vendors to hang themselves.
>=20
> If that means simply making poor choices, then OK. But if there are=20
> other cases where you feel that the specification of a feature is=20
> simply
>=20
> incoherent and the consequences not really thought out, then I think=20
> we need to discuss them and not propagate that state of affairs to
v4.1.
>=20
> -----Original Message-----
> From: Trond Myklebust [mailto:[email protected]]
> Sent: Friday, January 05, 2007 5:29 AM
> To: Benny Halevy
> Cc: Jan Harkes; Miklos Szeredi; [email protected];=20
> [email protected]; Mikulas Patocka;=20
> [email protected]; Jeff Layton; Arjan van de Ven
> Subject: Re: [nfsv4] RE: Finding hardlinks
>=20
>=20
> On Fri, 2007-01-05 at 10:28 +0200, Benny Halevy wrote:
>> Trond Myklebust wrote:
>>> Exactly where do you see us violating the close-to-open cache=20
>>> consistency guarantees?
>>>
>> I haven't seen that. What I did see is cache inconsistency when
> opening
>> the same file with different file descriptors when the filehandle
> changes.
>> My testing shows that at least fsync and close fail with EIO when the
> filehandle
>> changed while there was dirty data in the cache and that's good.
> Still,
>> not sharing the cache while the file is opened (even on a different
> file
>> descriptors by the same process) seems impractical.
>=20
> Tough. I'm not going to commit to adding support for multiple=20
> filehandles. The fact is that RFC3530 contains masses of rope with=20
> which to allow server and client vendors to hang themselves. The fact=20
> that the protocol claims support for servers that use multiple=20
> filehandles per inode does not mean it is necessarily a good idea. It=20
> adds unnecessary code complexity, it screws with server scalability=20
> (extra GETATTR calls just in order to probe existing filehandles), and
> it is insufficiently well documented in the RFC: SECINFO information=20
> is, for instance, given out on a per-filehandle basis, does that mean=20
> that the server will have different security policies? In some places,
> people haven't even started to think about the consequences:
>=20
> If GETATTR directed to the two filehandles does not return the
> fileid attribute for both of the handles, then it cannot be
> determined whether the two objects are the same. Therefore,
> operations which depend on that knowledge (e.g., client side
data
> caching) cannot be done reliably.
>=20
> This implies the combination is legal, but offers no indication as to=20
> how you would match OPEN/CLOSE requests via different paths. AFAICS=20
> you would have to do non-cached I/O with no share modes (i.e.=20
> NFSv3-style "special" stateids). There is no way in hell we will ever=20
> support non-cached I/O in NFS other than the special case of O_DIRECT.
>=20
>=20
> ...and no, I'm certainly not interested in "fixing" the RFC on this=20
> point in any way other than getting this crap dropped from the spec. I
> see no use for it at all.
>=20
> Trond
>=20
>=20
> _______________________________________________
> nfsv4 mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/nfsv4
_______________________________________________
nfsv4 mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/nfsv4
I won't be at connectathon either.
btw: we do have 2.5 hours scheduled for Prague. :-)
On Mon, Noveck, Dave wrote:
> I'm not going to be at Connectathon, but I could call in for a
> discussion.
>
> -----Original Message-----
> From: Benny Halevy [mailto:[email protected]]
> Sent: Monday, January 15, 2007 3:45 AM
> To: Noveck, Dave; Trond Myklebust
> Cc: Spencer Shepler; [email protected]; [email protected]
> Subject: Re: [nfsv4] RE: Finding hardlinks
>
> How about discussing this topic in the upcoming Connectathon?
>
> Benny
>
> Noveck, Dave wrote:
> > For now, I'm not going to address the controversial issues here,
> > mainly because I haven't decided how I feel about them yet.
> >
> > Whether allowing multiple filehandles per object is a good
> > or even reasonably acceptable idea.
> >
> > What the fact that RFC3530 talks about implies about what
> > clients should do about the issue.
> >
> > One thing that I hope is not controversial is that the v4.1 spec
> > should either get rid of this or make it clear and implementable.
> > I expect plenty of controversy about which of those to choose, but
> > hope that there isn't any about the proposition that we have to choose
>
> > one of those two.
> >
> >> SECINFO information is, for instance, given out on a per-filehandle
> >> basis, does that mean that the server will
> > have
> >> different security policies?
> >
> > Well yes, RFC3530 does say "The new SECINFO operation will allow the
> > client to determine, on a per filehandle basis", but I think that just
>
> > has to be considered as an error rather than indicating that if you
> > have two different filehandles for the same object, they can have
> > different security policies. SECINFO in RFC3530 takes a directory fh
> > and a name, so if there are multiple filehandles for the object with
> > that name, there is no way for SECINFO to associate different policies
>
> > with different filehandles. All it has is the name to go by. I think
>
> > this should be corrected to "on a per-object basis" in the new spec no
>
> > matter what we do on other issues.
> >
> > I think the principle here has to be that if we do allow multiple fh's
>
> > to map to the same object, we require that they designate the same
> > object, and thus it is not allowed for the server to act as if you
> > have multiple different object with different characteristics.
> >
> > Similarly as to:
> >
> >> In some places, people haven't even started to think about the
> >> consequences:
> >>
> >> If GETATTR directed to the two filehandles does not return the
> >> fileid attribute for both of the handles, then it cannot be
> >> determined whether the two objects are the same. Therefore,
> >> operations which depend on that knowledge (e.g., client side data
> >> caching) cannot be done reliably.
> >
> > I think they (and maybe "they" includes me, I haven't checked the
> > history
> > here) started to think about them, but went in a bad direction.
> >
> > The implication here that you can have a different set of attributes
> > supported for the same object based on which filehandle is used to
> > access the attributes is totally bogus.
> >
> > The definition of supp_attr says "The bit vector which would retrieve
> > all mandatory and recommended attributes that are supported for this
> > object. The scope of this attribute applies to all objects with a
> > matching fsid." So having the same object have different attributes
> > supported based on the filehandle used or even two objects in the same
>
> > fs having different attributes supported, in particular having fileid
> > supported for one and not the other just isn't valid.
> >
> >> The fact is that RFC3530 contains masses of rope with which to allow
> >> server and client vendors to hang themselves.
> >
> > If that means simply making poor choices, then OK. But if there are
> > other cases where you feel that the specification of a feature is
> > simply
> >
> > incoherent and the consequences not really thought out, then I think
> > we need to discuss them and not propagate that state of affairs to
> v4.1.
> >
> > -----Original Message-----
> > From: Trond Myklebust [mailto:[email protected]]
> > Sent: Friday, January 05, 2007 5:29 AM
> > To: Benny Halevy
> > Cc: Jan Harkes; Miklos Szeredi; [email protected];
> > [email protected]; Mikulas Patocka;
> > [email protected]; Jeff Layton; Arjan van de Ven
> > Subject: Re: [nfsv4] RE: Finding hardlinks
> >
> >
> > On Fri, 2007-01-05 at 10:28 +0200, Benny Halevy wrote:
> >> Trond Myklebust wrote:
> >>> Exactly where do you see us violating the close-to-open cache
> >>> consistency guarantees?
> >>>
> >> I haven't seen that. What I did see is cache inconsistency when
> > opening
> >> the same file with different file descriptors when the filehandle
> > changes.
> >> My testing shows that at least fsync and close fail with EIO when the
> > filehandle
> >> changed while there was dirty data in the cache and that's good.
> > Still,
> >> not sharing the cache while the file is opened (even on a different
> > file
> >> descriptors by the same process) seems impractical.
> >
> > Tough. I'm not going to commit to adding support for multiple
> > filehandles. The fact is that RFC3530 contains masses of rope with
> > which to allow server and client vendors to hang themselves. The fact
> > that the protocol claims support for servers that use multiple
> > filehandles per inode does not mean it is necessarily a good idea. It
> > adds unnecessary code complexity, it screws with server scalability
> > (extra GETATTR calls just in order to probe existing filehandles), and
>
> > it is insufficiently well documented in the RFC: SECINFO information
> > is, for instance, given out on a per-filehandle basis, does that mean
> > that the server will have different security policies? In some places,
>
> > people haven't even started to think about the consequences:
> >
> > If GETATTR directed to the two filehandles does not return the
> > fileid attribute for both of the handles, then it cannot be
> > determined whether the two objects are the same. Therefore,
> > operations which depend on that knowledge (e.g., client side
> data
> > caching) cannot be done reliably.
> >
> > This implies the combination is legal, but offers no indication as to
> > how you would match OPEN/CLOSE requests via different paths. AFAICS
> > you would have to do non-cached I/O with no share modes (i.e.
> > NFSv3-style "special" stateids). There is no way in hell we will ever
> > support non-cached I/O in NFS other than the special case of O_DIRECT.
> >
> >
> > ...and no, I'm certainly not interested in "fixing" the RFC on this
> > point in any way other than getting this crap dropped from the spec. I
>
> > see no use for it at all.
> >
> > Trond
> >
> >
> > _______________________________________________
> > nfsv4 mailing list
> > [email protected]
> > https://www1.ietf.org/mailman/listinfo/nfsv4
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> NFS maillist - [email protected]
> https://lists.sourceforge.net/lists/listinfo/nfs
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
Good. I plan to be in Prague.
Given that we should continue the discussion over email
and present a summary and possibly a proposal in Prague.
Benny
Spencer Shepler wrote:
> I won't be at connectathon either.
>
> btw: we do have 2.5 hours scheduled for Prague. :-)
>
>
> On Mon, Noveck, Dave wrote:
>> I'm not going to be at Connectathon, but I could call in for a
>> discussion.
>>
>> -----Original Message-----
>> From: Benny Halevy [mailto:[email protected]]
>> Sent: Monday, January 15, 2007 3:45 AM
>> To: Noveck, Dave; Trond Myklebust
>> Cc: Spencer Shepler; [email protected]; [email protected]
>> Subject: Re: [nfsv4] RE: Finding hardlinks
>>
>> How about discussing this topic in the upcoming Connectathon?
>>
>> Benny
>>
>> Noveck, Dave wrote:
>>> For now, I'm not going to address the controversial issues here,
>>> mainly because I haven't decided how I feel about them yet.
>>>
>>> Whether allowing multiple filehandles per object is a good
>>> or even reasonably acceptable idea.
>>>
>>> What the fact that RFC3530 talks about implies about what
>>> clients should do about the issue.
>>>
>>> One thing that I hope is not controversial is that the v4.1 spec
>>> should either get rid of this or make it clear and implementable.
>>> I expect plenty of controversy about which of those to choose, but
>>> hope that there isn't any about the proposition that we have to choose
>>> one of those two.
>>>
>>>> SECINFO information is, for instance, given out on a per-filehandle
>>>> basis, does that mean that the server will
>>> have
>>>> different security policies?
>>> Well yes, RFC3530 does say "The new SECINFO operation will allow the
>>> client to determine, on a per filehandle basis", but I think that just
>>> has to be considered as an error rather than indicating that if you
>>> have two different filehandles for the same object, they can have
>>> different security policies. SECINFO in RFC3530 takes a directory fh
>>> and a name, so if there are multiple filehandles for the object with
>>> that name, there is no way for SECINFO to associate different policies
>>> with different filehandles. All it has is the name to go by. I think
>>> this should be corrected to "on a per-object basis" in the new spec no
>>> matter what we do on other issues.
>>>
>>> I think the principle here has to be that if we do allow multiple fh's
>>> to map to the same object, we require that they designate the same
>>> object, and thus it is not allowed for the server to act as if you
>>> have multiple different object with different characteristics.
>>>
>>> Similarly as to:
>>>
>>>> In some places, people haven't even started to think about the
>>>> consequences:
>>>>
>>>> If GETATTR directed to the two filehandles does not return the
>>>> fileid attribute for both of the handles, then it cannot be
>>>> determined whether the two objects are the same. Therefore,
>>>> operations which depend on that knowledge (e.g., client side data
>>>> caching) cannot be done reliably.
>>> I think they (and maybe "they" includes me, I haven't checked the
>>> history
>>> here) started to think about them, but went in a bad direction.
>>>
>>> The implication here that you can have a different set of attributes
>>> supported for the same object based on which filehandle is used to
>>> access the attributes is totally bogus.
>>>
>>> The definition of supp_attr says "The bit vector which would retrieve
>>> all mandatory and recommended attributes that are supported for this
>>> object. The scope of this attribute applies to all objects with a
>>> matching fsid." So having the same object have different attributes
>>> supported based on the filehandle used or even two objects in the same
>>> fs having different attributes supported, in particular having fileid
>>> supported for one and not the other just isn't valid.
>>>
>>>> The fact is that RFC3530 contains masses of rope with which to allow
>>>> server and client vendors to hang themselves.
>>> If that means simply making poor choices, then OK. But if there are
>>> other cases where you feel that the specification of a feature is
>>> simply
>>>
>>> incoherent and the consequences not really thought out, then I think
>>> we need to discuss them and not propagate that state of affairs to
>> v4.1.
>>> -----Original Message-----
>>> From: Trond Myklebust [mailto:[email protected]]
>>> Sent: Friday, January 05, 2007 5:29 AM
>>> To: Benny Halevy
>>> Cc: Jan Harkes; Miklos Szeredi; [email protected];
>>> [email protected]; Mikulas Patocka;
>>> [email protected]; Jeff Layton; Arjan van de Ven
>>> Subject: Re: [nfsv4] RE: Finding hardlinks
>>>
>>>
>>> On Fri, 2007-01-05 at 10:28 +0200, Benny Halevy wrote:
>>>> Trond Myklebust wrote:
>>>>> Exactly where do you see us violating the close-to-open cache
>>>>> consistency guarantees?
>>>>>
>>>> I haven't seen that. What I did see is cache inconsistency when
>>> opening
>>>> the same file with different file descriptors when the filehandle
>>> changes.
>>>> My testing shows that at least fsync and close fail with EIO when the
>>> filehandle
>>>> changed while there was dirty data in the cache and that's good.
>>> Still,
>>>> not sharing the cache while the file is opened (even on a different
>>> file
>>>> descriptors by the same process) seems impractical.
>>> Tough. I'm not going to commit to adding support for multiple
>>> filehandles. The fact is that RFC3530 contains masses of rope with
>>> which to allow server and client vendors to hang themselves. The fact
>>> that the protocol claims support for servers that use multiple
>>> filehandles per inode does not mean it is necessarily a good idea. It
>>> adds unnecessary code complexity, it screws with server scalability
>>> (extra GETATTR calls just in order to probe existing filehandles), and
>>> it is insufficiently well documented in the RFC: SECINFO information
>>> is, for instance, given out on a per-filehandle basis, does that mean
>>> that the server will have different security policies? In some places,
>>> people haven't even started to think about the consequences:
>>>
>>> If GETATTR directed to the two filehandles does not return the
>>> fileid attribute for both of the handles, then it cannot be
>>> determined whether the two objects are the same. Therefore,
>>> operations which depend on that knowledge (e.g., client side
>> data
>>> caching) cannot be done reliably.
>>>
>>> This implies the combination is legal, but offers no indication as to
>>> how you would match OPEN/CLOSE requests via different paths. AFAICS
>>> you would have to do non-cached I/O with no share modes (i.e.
>>> NFSv3-style "special" stateids). There is no way in hell we will ever
>>> support non-cached I/O in NFS other than the special case of O_DIRECT.
>>>
>>>
>>> ...and no, I'm certainly not interested in "fixing" the RFC on this
>>> point in any way other than getting this crap dropped from the spec. I
>>> see no use for it at all.
>>>
>>> Trond
>>>
>>>
>>> _______________________________________________
>>> nfsv4 mailing list
>>> [email protected]
>>> https://www1.ietf.org/mailman/listinfo/nfsv4
>> -------------------------------------------------------------------------
>> Take Surveys. Earn Cash. Influence the Future of IT
>> Join SourceForge.net's Techsay panel and you'll get the chance to share your
>> opinions on IT & business topics through brief surveys - and earn cash
>> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
>> _______________________________________________
>> NFS maillist - [email protected]
>> https://lists.sourceforge.net/lists/listinfo/nfs
_______________________________________________
nfsv4 mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/nfsv4