Sorry, I made a typo in my original description
> The other design choice is to simply allow the albod to be written out
> as a flat file, and when an albod-aware application tries to modify it,
> only then does the albod-flat-file-package get exploded into its
> directory-based form. If the flat-file format is compressed (which
> would be a great idea since applications would now get compression for
> free) then only expanding an albod when it is necessary to read it will
^^^^
this should be "write" instead of "read"
Obviously reading from a compressed tar file without exploding it will
slow things down, but for data which is only accessed occasionally and
if disk space is an issue, it might be the right tradeoff.
> save disk space for albod's which are only getting access occasionally
> in read-only fashion.
Using compression (e.g. - tgzing the albod) is an interesting idea; it
does provide a new error condition that may or may not cause problems,
namely that of "ALBOD NOT EXPANDABLE."
So the new error condition only happens with an albod-aware application
attempts to write to a compressed albod. In that case, (1) the
application would be an albod-aware one, so it should be okay for it to
get a new kind of error, and (2) it doesn't have to be a new kind of
error; it can just be a ENOSPC, which can happen today when writing to
file.
- Ted
-
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/