|
From: Ian J. <ia...@da...> - 2003-04-09 13:15:26
|
Szakacsits Szabolcs writes ("Re: [Linux-NTFS-Dev] Implementing ntfsimage"):
> I wrote it for disk-to-disk copy (debug) _and_ efficient streaming backup
> purpose _and_ considering my time constrains. It can stream the data
> however I'm sure it's slower than a special format but works with standard
> tools [and most importantly it took only hours to implement by some minimal
> changes and massive deletion to ntfsresize].
Well, quite. But since I feel the need for something that can write a
stream sparse image format, I have the effort available :-).
> > If there is no separate image format then indeed you don't need a
> > restore utility. But, if you want a stream image format suitable for
> > writing to tapes, file transfer, etc., then you have to have a decoder
> > as well as an encoder.
>
> I do it as:
> ntfsimage -o - device | bzip2 ...
That's much slower than simply using a format which encodes the
sparseness. I'm not even sure if my machine can run bzip2 at tape
streaming speed - certainly many machines won't be able to. Also, and
I may be in a tiny minority here, but I don't like to put my backup
streams through a compression program because I think that's a bit
fragile.
> > I tend to think that sparse files are a bit of an anachronism, really.
>
> I think sparse files are very useful in many cases but filesystem support
> is ackward for them. IMHO only XFS can provide info to userspace tools
> about the location of holes. This results, among others, extremely poor
> performances in many cases and people start to think sparse files are a bit
> of an anachronism ;)
Err, quite :-).
I'm not saying sparse files aren't sometimes a useful technique. But
in the past, file formats which only make sense as sparse files have
turned out to be less useful because a smaller proportion of the
standard utilities work well on them.
So I think that there is room for both facilities: the optimised image
copy, and the conversion to a stream representation.
Szakacsits Szabolcs writes ("Re: [Linux-NTFS-Dev] Implementing ntfsimage"):
> On Tue, 8 Apr 2003, Ian Jackson wrote:
> > someone comes up with other uses. ext3image anyone?)
>
> There is e2image in e2fsprogs, I don't know if it works with ext3 or not.
> Probably.
I hadn't heard of that. As far as I can tell from its manpage it's
not quite the same thing as I think ntfsimage is or should be - but it
could benefit from being able to write a stream format.
> > * GNU tar's sparse file extensions - support 33-bit filesizes
>
> 33? I've never noticed large file support wouldn't work ...
Maybe the web page I was reading was out of date. It only had
12-character fields for the lengths and positions of holes. Ghads,
yet more hideous complication in the tar format ?
> > * partimage's image format - contains compression, CRCs, etc.,
> > which I think this is the wrong layer for, and which add
> > complexity. (Also, I'm not 100% convinced of the quality of some
> > of the partimage work.)
>
> I only checked the ntfs part and I wouldn't trust it at all.
It's nice to have a second opinion who agrees.
> > So, please comment on my format, which is described below. What form
>
> First I should convince myself a new format make sense. I can see several
> drawbacks: more code, image can't be used with standard tools, at least two
> steps is needed to get a real image, etc but can't really see benefits.
There's really no reason why ntfsimage shouldn't be able to do both.
I hope you'll accept my program which does write a stream format into
the linux-ntfs package. If not I'll be in a bit of a quandry: I can't
just distribute it separately because it wants to access various of
the utility code in ntfsprogs (and anyway, it conceptually ought to
live with the other tools).
Ian.
|
