|
From: Szakacsits S. <sz...@si...> - 2003-04-11 15:16:07
|
On Thu, 10 Apr 2003, Ian Jackson wrote: > > This can be done, of course, just by piping the output of the imager > into the restorer. The few resulting extra memory copies will > probably pale into insigificance next to the overhead of disk reads > and writes. Although, I'll try it and see. I think you're right. If I guess correctly how you implement them, yours will be even faster. The reason, ntfsclone is suboptimal for disk IO, it will seek a lot but not yours. It's minutes to fix this and ntfsclone should be faster. We will see then by how much ... > > I think this is the wrong level. I really don't want to have to create an > > image to be able to create a sparse file from that, that would take twice > > the space on disk and twice the time. > > You don't have to store the image stream anywhere (indeed, you'd > probably prefer not to for the reasons you say). True but there is something I didn't mention before, see below ... > Is the additional complexity in the imager worth it to avoid the need > to run two commands (or have a shell alias) ? It's not worth. This is why we need two tools. One for developers (ntfsclone) and one for users (ntfsimage). But still see below :) > Copying a sparse file to a partition isn't a restore, it's an > image-and-restore. So in my model you use the imager and restorer, > just as before. Doing the 'ntfsclone --metadata' (it's very important for NTFS development) in this model is: image --metadata (and several more options) restore wiping not needed and resident user data (and several more options) 3 tools and confusions. I don't think one want to populate ntfsimage with the --metadata stuff. On the other hand, ntfsclone _is_ very inefficient for the purpose ntfsimage is written. Use the right tool for the right job! :) Szaka |
