Messages in this thread | | | Date | Mon, 5 Jul 1999 15:52:17 +0200 | From | Jamie Lokier <> | Subject | Re: (reiserfs) Re: 20 years without semantic innovation is enough |
| |
Bernd Paysan wrote: > > I don't see what's wrong with "infinite" precision. These are files not > > potentially extremely large streams, right? > > cat foo/ >bar/ > > should be able to restore the attributes of all files in foo as is in the > directory bar. Either you implement even the file length in the fs as > string (uuaaah!), or you assign a restricted type to it, like int64.
1. I'm not convinced it should restore all _attributes_ [uid etc.]. If receive an albod in the mail and save it, I don't expect to see your uids in there. Not even if I'm root.
2. This came from a mention of an HTTP-style header: "Content-Length: 12345", so it's given that it'll parse a sequence of digits.
If you go around defining types like "int64" the kernel would have to parse the type string and support all the ones everyone else uses.
In which case there's a "largest supported size" that everyone has to agree on, or get a parse rejection. Why not forget the type restriction and just agree on a largest number?
One reason I can think of: so you detect max-size incompatibility early between systems, rather than getting a surprise failure the first time you try to transfer a large file.
> I describe the way it should have been implemented. XInternAtom queries > the X server for the number instead of forward-assigning it by the client. > Since filesystems are often used remotely, all filesystem semantics should > follow these design guidelines (no round-trips when avoidable).
Pros and cons. Forward-assignment lowers communication latency (which is really noticable for non-local X apps), but requires the server to maintain and look up per-client state.
-- Jamie
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |