|
From: Szakacsits S. <sz...@si...> - 2004-03-23 00:02:16
|
On Mon, 22 Mar 2004, Anton Altaparmakov wrote: > Ok. I will do that. Hopefully tomorrow. The question is now whether we > want to use the Linux kernel's idea of the geometry or the BIOS > often differ). I will go with using the kernel's idea for now. I'm afraid sometimes this is ok, other times the other one ... Well, what does Windows use? Probably the BIOS idea, so maybe that one would be better? Especially considering that Andries Brouwer wrote for 2.6 kernels: "There is no such thing as a "correct" disk geometry. Roughly speaking the kernel no longer attempts to report anything, so calling HDIO_GETGEO is useless (for this purpose)." Strictly speaking, of course he is not right and he was proven wrong several times. See in details this thread from November. http://groups.google.com/groups?threadm=WJ3h.3dk.1%40gated-at.bofh.it > Perhaps you could test again (I will let you know when I have done the > code) I tested the HDIO_GETGEO case, so there won't be any difference on my side. I just modified the relevant fields with hexedit and tried to boot XP. If they weren't right then XP didn't boot. > and if it works for you we can release it and see if anyone ever > complains... I'm sure :) This geometry issue is unsolvable. But the "best" guess could help a lot of people. If not then ntfsck could recommend other values :) BTW, probably I'll also commit some ntfsclone modifications, 1) Before cloning the (output_device_size < input_device_size) sanity check seems to be too strong. I think the correct is if (output_device_size < input_ntfs_size + 512) ==> error But first I need to think through all situations and scenarios. 2) The mount state of the output device isn't checked. Ooops. 3) There are LFS (large file support = 2 GB+) problems with smbfs. Details are here: http://sf.net/forum/forum.php?thread_id=1043909&forum_id=44085 Kernel 2.6 and 2.4.25 should support smbfs LFS but it seems it's buggy. Apparently it sends a slightly wrong request then XP or samba 3.0 do create (ftruncate) the large file but they answer with "wrong parameters" what smbfs interprets as EFBIG (File too large). I would really appreciate if other people could also confirm this kernel bug (smbfs maintainer didn't answer). Just try to ntfsclone a 2GB+ NTFS image to a Windows share (using NTFS on the remote Windows is a must) or a Samba 3.0 share using 2.4.25 or 2.6 kernel (using e.g. ntfsclone --metadata -o remote.img /dev/hda1 is also ok) Cheers, Szaka |
