Re: [Dan.Oscarsson@kiconsulting.se: Comments on NFSv4 rfc3010bis- 05 draft]

New Message Reply About this list Date view Thread view Subject view Author view Attachment view

From: Nicolas Williams (Nicolas.Williams@sun.com)
Date: 01/27/03-01:14:03 PM Z


Date: Mon, 27 Jan 2003 13:14:03 -0600
From: Nicolas Williams <Nicolas.Williams@sun.com>
Subject: Re: [Dan.Oscarsson@kiconsulting.se: Comments on NFSv4 rfc3010bis- 05 draft]
Message-ID: <20030127131403.C16765@binky.central.sun.com>

On Mon, Jan 27, 2003 at 09:47:27AM -0800, Noveck, Dave wrote:
> 
> > > But we cannot require it in storage, only on the wire.
> >
> > In storage we must leave the fileserver free to do as it pleases, but
> > for one restriction: it must use a reasonably canonical form in storage,
> > otherwise equal filenames with unequal encodings could be allowed.
> 
> How would define "reasonably canonical".  The requirement you are talking
> about is that you cannot have two different files in the same directory
> with canonically equivalent strings as name.  That affects the format
> that will be used in storage but leave it to the implementation to 
> decide exactly how.

Forms D, C, KD and KC are canonical, but the K forms could be said to be
more canonical (visually).

> > but cycles spent in
> > normalization, space dedicated to normalization data structures, *that*
> > is a big deal.
> 
> If it's spent on the client, no problem.  Time spent on the server
> on the other hand is very important :-)

My point exactly.

> > This is why I'm for form D (on the wire as an optimization).
> 
> It seems that form D can be checked by just looking for decomposable
> characters and rejecting if any is found.  On the other hand, it
> seems, that you need some kind of state machine to check form C. 

D also specifies an order for combining marks; this order has to be
checked and enforced.  Even when decomposing as a first step to
re-compose (for form C) this order has to be correct so as to minimize
the tables needed for composition (else they get ridiculously large).

> I think kernel and non-kernel people tend to have different view of 
> what is considered too expensive. 

Absolutely.

Nico
-- 


New Message Reply About this list Date view Thread view Subject view Author view Attachment view

This archive was generated by hypermail 2.1.2 : 03/04/05-01:50:50 AM Z CST