|
From: Szakacsits S. <sz...@si...> - 2004-03-31 08:51:48
|
On Tue, 30 Mar 2004, SourceForge.net wrote: > I see a 25 second delay at 0.65% complete. Then I see another delay at > 7.40% complete, and after 30 seconds it fails. During these two > delays, the hard drive light at the remote (destination) PC is > continuously on (a detail I hadn't noticed before!). This is a very important detail and explains things (please see below). Good catch! > 3) The same thing happens when the output file is on either of two different > shares on the remote PC, which happen to be on two different physical drives. > So, although I have not defragged the remote PC, the fact that I get delays > at the same place on two different drives leads me to believe it's not related > to fragmentation on the remote. Right. It would be very nice to test this if the remote host isn't Windows with NTFS but a Unix Samba server. I bet you wouldn't have this problem unless the SMB (CIFS) protocol mandates this must be the behavior (I doubt). > My guess interpretation of this is that when ntfsclone performs a "go > to position" operation that is a large skip, the ntfs driver on the > remote PC must physically write zeros to all those skipped blocks. If > this operation takes longer than 30 seconds, something (probalby in > smbfs) times out. Yes, this is what's happening. I also thought about this earlier but I excluded it without mentioning because NTFS does handle sparse files (a file is sparse if it has unallocated blocks, these must be presented to the user as zeros). But they are handled differently on NTFS as I thought (the Unix way). In the given case, the first sparse file operation is ftruncate, setting the file size. This works immediately (the 'lfs' smbfs mount option is needed for large files as we figured out) so the sparse file was successfully created. Thus I thought everything should be fine related to sparse file issues. I was wrong. You just proved, the further file IO operations doesn't work the same way on NTFS as on Unix filesystems because ... [ ... some search on the net ... ] ... apparently one must set explicitely the file sparse on NTFS to get the same behaviour as on Unix (no extra coding needed on Unix). I'm not sure this is possible via smbfs ... actually I'm afraid, probably it's quite impossible. Workaround for this case is what you also reported to work (but it's ususally much slower, however in that case it should be compressed better). ntfsclone -o - device > /mnt/windows_share/ntfs.img I'll add detection and a diagnostic message, suggestion to ntfsclone for the failing case. As for the long term, there will be an additional image format that won't have this problem. Hopefully it will be Partimage's image format, we're already investigating/discussing how to replace Partimage experimental NTFS support with the stable Linux-NTFS code. That way people would have both GUI and command line backup/restore tools using the same image format and NTFS code. > Hope this helps, Thanks Trey, it helped a lot! Szaka |
