lkml.org 
[lkml]   [1999]   [Jul]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [RFC] File flags handling - proposal for API.
Date
> Let me get this straight: we're talking about writing a *new copy* of a
> compound document, right? [Leaving the old copy as a backup.] [Or maybe
> you're trying to say that backup copies of a document are stupid?]
>
> And the claim is that introducing "file system internal to the file"
> is somehow going to make that faster.

If this is addressed to me, you are severely confused.

Hmmm...

Some people seem to think that using a "file system internal to the file"
will be good, since it lets an app avoid writing out a whole new file
when something in the middle needs to expand. This apparent enhancement
is not free though, as I showed in my response to Viro & Reiser. It is
in fact much slower for many common operations. You pay either way.

You get performance only by avoiding the extra layer. This can be done
via normal directories or via compound document support in the existing
filesystem layer. Normal directories leave you with user-interface
problems and complicated code in every app. (note: the NeXT is dead)
Compound document support is not at all a pretty feature, but it does
seem to solve the problems.

Choose your poison.

-
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/

\
 
 \ /
  Last update: 2005-03-22 13:52    [W:0.035 / U:0.516 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site