|
From: Szakacsits S. <sz...@si...> - 2004-02-25 12:18:40
|
Hello Pelle, I CC: linux-ntfs-dev because you made an interesting point. On Wed, 25 Feb 2004, Per Olofsson wrote: > I have a question regarding ntfsclone: Please feel free to ask anytime. I'm very interested what bothers users, what they think, what they find confusing, and so on. > Since ntfsclone uses sparse files, where holes represent unused blocks > (clusters) of the cloned partition, I thought it would be possible to > use this functionality to avoid writing unused blocks when restoring > an image to a hard disc partition. Right. Here is the simplest scenario: backup: ntfsclone -o mybackup.img /dev/hda1 restore: ntfsclone -O /dev/hda1 mybackup.img The restoration will not write the unused blocks back to the disk. Both action should take about the same time and this time is limited only by the maximal speed of the disk and how good the kernel is scheduling the disk IO. Disk seeks are minimalised by ntfsclone. > But as far as I can tell, sparse files are just a filesystem level > optimisation, Right. > and there is no way for programs to tell where the holes in a sparse > file actually are. Well, there is (FIBMAP ioctl) but it's not used because it's very inefficient. Only XFS supports this efficiently. I wrote about these in the ntfsclone manual. Did you check it out? http://linux-ntfs.sourceforge.net/man/ntfsclone.html > It seems like tar and cp just scans the file for large chunks of > zeroes and then assumes that they represent holes. Unfortunately true. It's also mentioned in the ntfsclone manual. > If this method is used to restore an image to a partition, I assume > that if there actually *is* files on the image containing longer > streams of zeroes, these will simply not get written to the target > partition, thus being replaced by whatever garbage was there > before. This is not true. There are only two ways to restore an image to a partition: 1) ntfsclone - it does the job correctly and saves the time writting back unused blocks. 2) dd - it writes _everything_. It will also write the zeros, thus it's slower. What about cp and tar? They are unable to restore an _image_ to a block device (partition), they will give an error when one tries to open the device. And now comes the interesting part. What if you want to copy/create an image with cp or tar with the -S option to a _file_? Can they mess up data? The answer is again no. Both will create a new file and if they detect there is somewhere only zeros then altough they skip that part in the target but the filesystem will set them 0. They will be also sparse files, no messed up data. I hope I could explain the issue, if not please give a specific example when you think the process would be unreliable. > And therefore, this use of ntfsclone is not reliable. Is this correct? It's not correct. I don't know many NTFS imaging softwares but I've heard several times from several sources that e.g. Ghost can trash NTFS. Partimage, Mondo (based on Partimage) is unreliable. I wrote about it here longer: http://www.partimage.org/forums/viewtopic.php?t=5 So the only tools I would trust at present to backup/restore NTFS is dd and ntfsclone. Well, actually I do use it for almost a year _very_ intensively because it's needed for development (backups and automatic testing all the time) and I've never had any problem. Others didn't report problems either. Szaka |
