|
From: Per O. <pe...@ds...> - 2004-02-25 18:14:32
|
On Wed, Feb 25, 2004 at 17:50 +0100, Szakacsits Szabolcs wrote: > > Still, there is one drawback with ntfsclone. It's not possible, AFAIK, > > to restore images efficiently from a pipe. If you want to put an image > > on a web server, or more importantly, if you want to multicast an > > image to many computers, you need to have some kind of temporary > > storage on the computer(s) you're writing the image to. > > The 'temporary storage' isn't true but the 'efficiently' is true. E.g. > > ntfsclone -o - dev | gzip -2c | ssh -C host 'gunzip -c | dd of=dev' > > No temporary storage but it also doesn't have optimal network and disk > usage. What I meant was that, as you say, you can't get efficiency without temporary storage. Of course, you don't need temporary storage if you use the inefficient approach. > About one year ago, after lot of discussions with Ian Jackson, we agreed > to make three different utilities: > > - ntfsimage and restoreimage > - ntfsclone > > He wrote the first two, exactly what you wrote but never sent to us. I see. The reason I never sent anything to you is that my utilities are just a hack and don't really work as they are now. Are ntfsimage and restoreimage available somewhere? > So only ntfsclone left. I needed it badly for development to debug user > issues (see --metadata option) and to do things as fast and efficient as > possible (no much free time to play with NTFS). Full backup functionality > came mostly as a side-effect. ... > Yes, there is definitely need for it. I also mentioned this earlier. I'll > think about it again how it would be the best to progress :) Suggestions > are of course also welcomed :) ntfsclone and ntfsimage do essentially the same thing, they skip over unused blocks. The output format is merely a detail and could be chosen with a command-line option. I think it would be better if they were one utility, in order to reduce duplicated efforts. -- Pelle |
