|
From: Anton A. <ai...@ca...> - 2004-03-23 09:58:48
|
On Tue, 2004-03-23 at 00:02, Szakacsits Szabolcs wrote: > 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? But the BIOS is more difficult to get to. )-: In 2.6 kernels you can get it if the user (as root) has mounted sysfs and has loaded the edd module or has compiled it into the kernel. The problem is still we don't know where they mounted it. E.g. on my SuSE 9.0 / 9.1 beta 1 hybrid system I have sysfs on /sys and after doing a "modprobe edd" I can see: $ cd /sys/firmware/edd/int13_dev80 $ cat default_cylinders 0x3fff $ cat default_heads 0x10 $ cat default_sectors_per_track 0x3f If I use hdparm -g /dev/hda (I assume this uses HDIO_GETGEO): $ sudo hdparm -g /dev/hda /dev/hda: geometry = 16383/255/63, sectors = 160086528, start = 0 So the number of heads already disagees here. Which is better? No idea... )-: The problem is of course that the bios edd stuff I assume will only report devices bootable by the bios and I have no idea how we would manage to find out which of the entries in sysfs.../edd is the right device and things like that... Far too much code in my opinion for something like that. For now I am just going to use HDIO_GETGEO so it stays simple and I will provide command line options for providing each of the values manually. And in the man page I will say something to the effect of "if Windows doesn't boot, try supplying different values for the CHS values. You can obtain them from your BIOS, the EDD service if running a 2.6 kernel, hdparm -i /dev/hda, /proc/ide/hda/geometry, etc..." > 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 :) Yes, you are right. It is completely unsolvable. The only way we could solve it is if we knew _how_ windows determines the geometry and then we use the same method, provided Linux implements it... > 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) Sorry but I don't have any NTFS partitions of that size so I can't try it. )-: Best regards, Anton -- Anton Altaparmakov <aia21 at cam.ac.uk> (replace at with @) Unix Support, Computing Service, University of Cambridge, CB2 3QH, UK Linux NTFS maintainer / IRC: #ntfs on irc.freenode.net WWW: http://linux-ntfs.sf.net/ & http://www-stu.christs.cam.ac.uk/~aia21/ |
