Re: vmware reads disk on non-sector boundary
Bakul Shah wrote: phk writes: You are welcome to peruse the mail-archives to find out such historically interesting decisions. I am aware of the technical arguments discussed via -arch, -current -hackers. I just don't agree with them (seems like most hackers who are afraid to cross you). Here is a rehash of all the arguments which involved Kirk McKusick, or people quoting or responding to him: http://www.FreeBSD.org/cgi/search.cgi?words=kirk+AND+block+AND+devicesmax=25sort=scoreindex=allsource=freebsd-arch It includes the Linux emulation issue for Sybase and Informix, as well as the EXT2FS utilities, system dump images (only this last, since fixed), etc.. The VMware issue is a Linux emulation issue. There are a couple of MSDOS FS layouts that would result in the same issue, as well as WINE issues. These are fixable, because source code is available. My comments in response to Kirk are also there, along with everyone else who voiced a response. Julian writes: He had some backing, for example Kirk made a good argument for removing them. The arguments about not being able to do devfs and geom without removing them are of course specious as it can and was done before by others. Hmm.. I don't recall Kirk McKusick's argument for removing a buffered block device. Here is the most specific statement; it quotes, inclusively, a previous statement by him on the issue. http://www.FreeBSD.org/cgi/getmsg.cgi?fetch=81284+85591+/usr/local/www/db/text/1999/freebsd-arch/19991017.freebsd-arch For the record, I am against a bikeshed, now, just as much as I was against the removal of block devices, then. What's done is done, and all that's left for people to do is to pick up the pieces that come from the changes they make. One provides a stacking system for disk geometries wand layouts where the upper interface is the same as that provided by the actual disk. Thanks! This is the (now old) slice vs. GEOM argument. Ignore it. Core did not override Poul's actions in this regard at the time, it's no use revisiting them now, if nothing useful is going to come from it. We are all already on record as to which positions we supported, though it's harder to search for slice and get useful results from the mailing list archive search engine. Here is Julian's initial announcement of his slice code that went with his devfs code: http://docs.freebsd.org/cgi/getmsg.cgi?fetch=689041+0+archive/1997/freebsd-hackers/19971123.freebsd-hackers -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: vmware reads disk on non-sector boundary
On Thu, 3 Oct 2002, Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], Bakul Shah writes: How hard would it be to bring back block devices without GEOM? Not at all hard, pretty trivial in fact. The easiest way is to restore the old code and use a minor number hack or ioctl to enable it. I had better do it instead of complaining about it. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: vmware reads disk on non-sector boundary
In message [EMAIL PROTECTED], Bakul Shah writes: Oh well. I am not going to argue about this over and over and over again. Thankyou, a very wise decision sir! -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: vmware reads disk on non-sector boundary
In message p05111710b9c1484025de@[128.113.24.47], Garance A Drosihn writes: I also have a partition with freebsd-current from two or three days ago, and all the latest versions of the ports. Every time I try to start vmware2 on the newer system, the hardware dies. Sometimes it automatically reboots, other times it freezes up and I have to force-reboot it (sometimes by unplugging it from the wall). See the patch I posted in: http://www.FreeBSD.org/cgi/getmsg.cgi?fetch=0+6285+/usr/local/www/db/text/2002/freebsd-emulation/20020908.freebsd-emulation There may still be further issues, but it allowed me to use vmware2 on a current from a week or two ago. Ian To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: vmware reads disk on non-sector boundary
On Thu, Oct 03, 2002 at 09:04:04AM +0100, Ian Dowse wrote: See the patch I posted in: http://www.FreeBSD.org/cgi/getmsg.cgi?fetch=0+6285+/usr/local/www/db/text/2002/freebsd-emulation/20020908.freebsd-emulation There may still be further issues, but it allowed me to use vmware2 on a current from a week or two ago. That's only for virtual disks, and that is not where the problem is (was). For most people this is not a solution. I have an almost-ready patch that implements linux_read() syscall. This will check if we are reading from a raw disk and in that case it will enlarge the read() to the next sector boundary. I have it working in the kernel but I have problems returning the right read buffer to userland. Mark -- Mark SantcroosRIPE Network Coordination Centre http://www.ripe.net/home/mark/New Projects Group/TTM To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: vmware reads disk on non-sector boundary
In message [EMAIL PROTECTED], Mark Santcroos writes: On Thu, Oct 03, 2002 at 09:04:04AM +0100, Ian Dowse wrote: There may still be further issues, but it allowed me to use vmware2 on a current from a week or two ago. That's only for virtual disks, and that is not where the problem is (was). For most people this is not a solution. True, it won't fix the problems you reported with raw disks, but it stops vmware from instantly panicking on recent -currents and that is the first problem you will encounter with the port. I tend to run vmware either diskless or with virtual disks, so I wouldn't notice the raw disk issues. Ian To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: vmware reads disk on non-sector boundary
On Thu, 3 Oct 2002, Mark Santcroos wrote: I have an almost-ready patch that implements linux_read() syscall. This will check if we are reading from a raw disk and in that case it will enlarge the read() to the next sector boundary. I have it working in the kernel but I have problems returning the right read buffer to userland. Unbreaking block devices would be a better solution. Without buffering, reads of raw disks using an unbuffered linux_read() might be sector size times slower than they should be. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: vmware reads disk on non-sector boundary
On Thu, Oct 03, 2002 at 09:50:45PM +1000, Bruce Evans wrote: Unbreaking block devices would be a better solution. Without buffering, reads of raw disks using an unbuffered linux_read() might be sector size times slower than they should be. You are right. The quick and dirty hack I had in mind was less quick and more dirty than I expected ;-) What was the reason for the removal of block devices anyway? It would be nice if you would tell me some background about that.. :) Mark -- Mark SantcroosRIPE Network Coordination Centre http://www.ripe.net/home/mark/New Projects Group/TTM To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: vmware reads disk on non-sector boundary
In message [EMAIL PROTECTED], Mark Santcroos writes: On Thu, Oct 03, 2002 at 09:50:45PM +1000, Bruce Evans wrote: Unbreaking block devices would be a better solution. Without buffering, reads of raw disks using an unbuffered linux_read() might be sector size times slower than they should be. You are right. The quick and dirty hack I had in mind was less quick and more dirty than I expected ;-) What was the reason for the removal of block devices anyway? It would be nice if you would tell me some background about that.. :) It's well documented in the mail-archives actually. The short story: 1. We don't in general assign a special vnode type to device modes, instead we assign multiple device nodes, SCSI tapes is an example of this. 2. The vnode layer already have enough trouble aliasing /dev/fd0, /mnt/dev/fd0, /usr/jail/dev/fd0, /cdrom/dev/fd0 (you get the idea), we do not need to make it even harder by also aliasing /dev/fd0 and /dev/rfd0. 3. Write ordering on buffered devices were unspecified. In other words, you cannot use it for anything which even remotely smells of transactions, because you have no way to know when your writes have hit the disk and in which order they did so. 4. No write errors were reported back to userland. (Given 3 and 4, it follows that use of block devices for any sort of data you happen to like is a very bad idea.) 5. Block devices was in the way of getting DEVFS working in an architecturally sane manner. So they were removed, and good riddance. If a buffered access-mode on block devices is desired, it should be implemented either as an ioctl controllable feature, or as a GEOM module. The latter is probably by far the easiest way. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: vmware reads disk on non-sector boundary
On Thu, 3 Oct 2002, Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], Mark Santcroos writes: On Thu, Oct 03, 2002 at 09:50:45PM +1000, Bruce Evans wrote: Unbreaking block devices would be a better solution. Without buffering, ... What was the reason for the removal of block devices anyway? It would be nice if you would tell me some background about that.. :) It's well documented in the mail-archives actually. The short story: Shorter story: phk didn't like them. 1. We don't in general assign a special vnode type to device modes, instead we assign multiple device nodes, SCSI tapes is an example of this. 2. The vnode layer already have enough trouble aliasing /dev/fd0, /mnt/dev/fd0, /usr/jail/dev/fd0, /cdrom/dev/fd0 (you get the idea), we do not need to make it even harder by also aliasing /dev/fd0 and /dev/rfd0. Aliases that differ in type are slightly easier to handle than aliases that differ by name or mount point. They are diferent devices so they have different vnodes, and the aliasing problems for them are quite different than the vnode aliasing problems caused by having the same device under different mount points. E.g., slices and partitions allow configuring 31*7 aliases per drive for hard drives (31 slices with 7 configuring partitions each). Slices and partitions may overlap, giving something more complicated than aliases. The vnode layer doesn't understand any of this. 3. Write ordering on buffered devices were unspecified. In other words, you cannot use it for anything which even remotely smells of transactions, because you have no way to know when your writes have hit the disk and in which order they did so. This is no different than for regular files. 4. No write errors were reported back to userland. Actually, write errors were reported at fsync() and close() time in the same way as for regular files. fsync()'s handling of write errors was broken for both regular files and buffered devices at the time buffered devices were axed. (Given 3 and 4, it follows that use of block devices for any sort of data you happen to like is a very bad idea.) It follos similarly that use of fil systems is a bad idea :-). You You should only use a databases on raw disks if you value your data. 5. Block devices was in the way of getting DEVFS working in an architecturally sane manner. This can be considered a feature. So they were removed, and good riddance. If a buffered access-mode on block devices is desired, it should be implemented either as an ioctl controllable feature, or as a GEOM module. The latter is probably by far the easiest way. It was desired, and was sort of promised. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: vmware reads disk on non-sector boundary
In message [EMAIL PROTECTED], Bruce Evans writes: If a buffered access-mode on block devices is desired, it should be implemented either as an ioctl controllable feature, or as a GEOM module. The latter is probably by far the easiest way. It was desired, and was sort of promised. And we're close to the point where it can happen... -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: vmware reads disk on non-sector boundary
Ian Dowse wrote: In message p05111710b9c1484025de@[128.113.24.47], Garance A Drosihn writes: I also have a partition with freebsd-current from two or three days ago, and all the latest versions of the ports. Every time I try to start vmware2 on the newer system, the hardware dies. Sometimes it automatically reboots, other times it freezes up and I have to force-reboot it (sometimes by unplugging it from the wall). See the patch I posted in: http://www.FreeBSD.org/cgi/getmsg.cgi?fetch=0+6285+/usr/local/www/db/text/2002/freebsd-emulation/20020908.freebsd-emulation There may still be further issues, but it allowed me to use vmware2 on a current from a week or two ago. you also might try to look at the patch in PR port/41784 http://www.freebsd.org/cgi/query-pr.cgi?pr=41784 i'm running vmware2 on my not so -current with the patch. if this is outdated feel free to close the PR. thanks, max To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: vmware reads disk on non-sector boundary
It was desired, and was sort of promised. I never understood why removal of block devices was allowed in the first place. phk's reasons don't seem strong enough to any unix wizard I have talked to. Did the majority of the core really think the change was warranted? Removing compatibility when the change _doesn't_ bring a *substantial* improvement doesn't seem right. How hard would it be to bring back block devices without GEOM? Is there a write up somewhere on what GEOM is and its benefits? I'd hate to see it become the default without understanding it (and no, reading source code doesn't do it). Thanks! -- bakul To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: vmware reads disk on non-sector boundary
At 10:11 AM +0200 10/3/02, Mark Santcroos wrote: On Thu, Oct 03, 2002 at 09:04:04AM +0100, Ian Dowse wrote: See the patch I posted in: http://www.FreeBSD.org/cgi/getmsg.cgi?fetch=0+6285+/usr/local/www/db/text/2002/freebsd-emulation/20020908.freebsd-emulation There may still be further issues, but it allowed me to use vmware2 on a current from a week or two ago. That's only for virtual disks, and that is not where the problem is (was). For most people this is not a solution. I have an almost-ready patch that implements linux_read() syscall. This will check if we are reading from a raw disk and in that case it will enlarge the read() to the next sector boundary. I have it working in the kernel but I have problems returning the right read buffer to userland. Hmm. I might not be any good for the raw-disk testing. All I use are virtual disks. (I have a 32-gig disk with a bunch of 2-gig virtual-disks on it. With that many systems, it's much easier for me to deal with files than a whole bunch of small partitions on the raw disk). The patch from Ian sounds like it would be interesting for me. I'll have to try that. It would be great if I could get back to regularly running an up-to-date current. -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: vmware reads disk on non-sector boundary
On Thu, Oct 03, 2002 at 09:37:07AM -0700, Bakul Shah wrote: Is there a write up somewhere on what GEOM is and its benefits? I'd hate to see it become the default without understanding it (and no, reading source code doesn't do it). Bakul, there's been ample discussion of what GEOM is in the last year. I suggest you read the list archives. Joe -- As far as the laws of mathematics refer to reality, they are not certain; and as far as they are certain, they do not refer to reality. - Albert Einstein, 1921 msg37218/pgp0.pgp Description: PGP signature
Re: vmware reads disk on non-sector boundary
In message [EMAIL PROTECTED], Bakul Shah writes: I never understood why removal of block devices was allowed in the first place. You are welcome to peruse the mail-archives to find out such historically interesting decisions. You are not welcome to build another bikeshed over it. How hard would it be to bring back block devices without GEOM? Not at all hard, pretty trivial in fact. Is there a write up somewhere on what GEOM is and its benefits? I'd hate to see it become the default without understanding it (and no, reading source code doesn't do it). Man 4 geom is a good place to start. There will also be a tutorial friday afternoon about GEOM at BSDCONeuro2002 in amsterdam next month. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: vmware reads disk on non-sector boundary
On Thu, 3 Oct 2002, Bakul Shah wrote: It was desired, and was sort of promised. I never understood why removal of block devices was allowed in the first place. phk's reasons don't seem strong enough to any unix wizard I have talked to. Did the majority of the core really think the change was warranted? Removing compatibility when the change _doesn't_ bring a *substantial* improvement doesn't seem right. He had some backing, for example Kirk made a good argument for removing them. The arguments about not being able to do devfs and geom without removing them are of course specious as it can and was done before by others. How hard would it be to bring back block devices without GEOM? Even WITH geom it would be possible. Is there a write up somewhere on what GEOM is and its benefits? I'd hate to see it become the default without understanding it (and no, reading source code doesn't do it). The concept is good. One provides a stacking system for disk geometries wand layouts where the upper interface is the same as that provided by the actual disk. Using devfs, one can export the 'top suface' of the stack as accessible devices. Theoretically the latyers can apply themselvces as a device is recognised and each layer type 'probes' the device to figure out it it belongs there. It's not rocket science as far as an idea goes. The trick is in the implementation. Locking and access control of parts gets quite tricky. for a similar idea look in the cvs tree for the now removed 'slice' code that did teh same thing. /sys/dev/slice It supported black and character device nodes for each partition. Thanks! -- bakul To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: vmware reads disk on non-sector boundary
On Thu, Oct 03, 2002 at 05:57:56PM +0200, Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], Bruce Evans writes: If a buffered access-mode on block devices is desired, it should be implemented either as an ioctl controllable feature, or as a GEOM module. The latter is probably by far the easiest way. It was desired, and was sort of promised. And we're close to the point where it can happen... So 'ignoring' the historic facts, and assuming that we just want block devices, we can do such a thing in GEOM in the future? Is this something you will be doing yourself Poul, or is it just that you are saying that it is possible? If not, I really would like to help to get vmware back, but I don't know anything more about GEOM than option\t\tGEOM. Mark -- Mark SantcroosRIPE Network Coordination Centre http://www.ripe.net/home/mark/New Projects Group/TTM To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: vmware reads disk on non-sector boundary
On Fri, Oct 04, 2002 at 12:53:52AM +0200, Mark Santcroos wrote: So 'ignoring' the historic facts, and assuming that we just want block devices, we can do such a thing in GEOM in the future? Is this something you will be doing yourself Poul, or is it just that you are saying that it is possible? If not, I really would like to help to get vmware back, but I don't know anything more about GEOM than option\t\tGEOM. There's a pretty good man page, man geom. Cheers, Joe -- As far as the laws of mathematics refer to reality, they are not certain; and as far as they are certain, they do not refer to reality. - Albert Einstein, 1921 msg37237/pgp0.pgp Description: PGP signature
Re: vmware reads disk on non-sector boundary
phk writes: You are welcome to peruse the mail-archives to find out such historically interesting decisions. I am aware of the technical arguments discussed via -arch, -current -hackers. I just don't agree with them (seems like most hackers who are afraid to cross you). You are not welcome to build another bikeshed over it. If block devices are trivial to build with geom, they should've been not removed until geom was in place. Oh well. I am not going to argue about this over and over and over again. But I was hoping sanity would prevail (my hopes were raised with perl-5's removal and Julian Bruce piping up). Man 4 geom is a good place to start. Thanks. More on this in a separate email. There will also be a tutorial friday afternoon about GEOM at BSDCONeuro2002 in amsterdam next month. Too far to travel :-) Julian writes: He had some backing, for example Kirk made a good argument for removing them. The arguments about not being able to do devfs and geom without removing them are of course specious as it can and was done before by others. Hmm.. I don't recall Kirk McKusick's argument for removing a buffered block device. One provides a stacking system for disk geometries wand layouts where the upper interface is the same as that provided by the actual disk. Thanks! -- bakul To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: vmware reads disk on non-sector boundary
On Wed, Sep 25, 2002 at 09:39:30PM +0100, Josef Karthauser wrote: I thought that we hacked around this in the linuxulator 18 months ago by transparently converting block calls into character calls behind the scenes. Either this has been removed or something else is wrong. This isn't the case for me on -STABLE. I had to create block devices for raw disks to work. BMS To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: vmware reads disk on non-sector boundary
On Thu, Sep 26, 2002 at 09:47:33AM +0100, Bruce M Simpson wrote: On Wed, Sep 25, 2002 at 09:39:30PM +0100, Josef Karthauser wrote: I thought that we hacked around this in the linuxulator 18 months ago by transparently converting block calls into character calls behind the scenes. Either this has been removed or something else is wrong. This isn't the case for me on -STABLE. I had to create block devices for raw disks to work. Yes that needs to be done one -stable. The hack I was talking about was for -current only where block devices don't exist anymore. Joe -- As far as the laws of mathematics refer to reality, they are not certain; and as far as they are certain, they do not refer to reality. - Albert Einstein, 1921 msg37085/pgp0.pgp Description: PGP signature
Re: vmware reads disk on non-sector boundary
On Thu, Sep 26, 2002 at 09:52:37AM +0100, Josef Karthauser wrote: On Thu, Sep 26, 2002 at 09:47:33AM +0100, Bruce M Simpson wrote: On Wed, Sep 25, 2002 at 09:39:30PM +0100, Josef Karthauser wrote: I thought that we hacked around this in the linuxulator 18 months ago by transparently converting block calls into character calls behind the scenes. Either this has been removed or something else is wrong. This isn't the case for me on -STABLE. I had to create block devices for raw disks to work. Yes that needs to be done one -stable. The hack I was talking about was for -current only where block devices don't exist anymore. It took a while to find, but this is the hack I was referring to: Take a look at /sys/compat/linux/linux_stats.c, revision 1.29 date: 2001/01/14 23:33:50; author: joe; state: Exp; lines: +18 -11 Instead of hard coding the major numbers for IDE and SCSI disks look in the device's cdevsw for the D_DISK flag. revision 1.28 date: 2000/12/29 00:44:42; author: paul; state: Exp; lines: +15 -1 Map FreeBSD character device hard disks to Linux block device hard disks. This fixes the problem with VMWARE not being able to use raw disks. Joe -- As far as the laws of mathematics refer to reality, they are not certain; and as far as they are certain, they do not refer to reality. - Albert Einstein, 1921 msg37099/pgp0.pgp Description: PGP signature
Re: vmware reads disk on non-sector boundary
On Thu, 26 Sep 2002, Josef Karthauser wrote: On Thu, Sep 26, 2002 at 09:52:37AM +0100, Josef Karthauser wrote: On Thu, Sep 26, 2002 at 09:47:33AM +0100, Bruce M Simpson wrote: On Wed, Sep 25, 2002 at 09:39:30PM +0100, Josef Karthauser wrote: I thought that we hacked around this in the linuxulator 18 months ago by transparently converting block calls into character calls behind the scenes. Either this has been removed or something else is wrong. This isn't the case for me on -STABLE. I had to create block devices for raw disks to work. Yes that needs to be done one -stable. The hack I was talking about was for -current only where block devices don't exist anymore. It took a while to find, but this is the hack I was referring to: Take a look at /sys/compat/linux/linux_stats.c, revision 1.29 date: 2001/01/14 23:33:50; author: joe; state: Exp; lines: +18 -11 Instead of hard coding the major numbers for IDE and SCSI disks look in the device's cdevsw for the D_DISK flag. revision 1.28 date: 2000/12/29 00:44:42; author: paul; state: Exp; lines: +15 -1 Map FreeBSD character device hard disks to Linux block device hard disks. This fixes the problem with VMWARE not being able to use raw disks. but it still doesn't help with partial block reads.. Joe -- As far as the laws of mathematics refer to reality, they are not certain; and as far as they are certain, they do not refer to reality. - Albert Einstein, 1921 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: vmware reads disk on non-sector boundary
On Thu, Sep 26, 2002 at 07:50:36PM +0100, Josef Karthauser wrote: It took a while to find, but this is the hack I was referring to: Take a look at /sys/compat/linux/linux_stats.c, Thanks for taking the effort for looking this up. However, the function in question - newstat_copyout - is not in 'action' here. (had set a breakpoint in ddb) It's still unclear to me what recent change broke vmware. The removal of block devices Julian referred to is not something recent, is it? I mentioned earlier to you that I am writing a linux_read system call. This will basicly work, as long as I will be able to do the following (in pseudo code): linux_read(readsize) { if (read_is_on_raw_device) readlen = (readlen % BLOCKSIZE) + BLOCKSIZE; /* or something like this plus some other mangling of the buffer */ read(readlen); } The only thing I have to find out is the check to see whether it is a read on a raw device or not. I strongly prefer to do the check in linux_read and not in the disk layer code. (It would be easier, but not cleaner) Mark -- Mark Santcroos RIPE Network Coordination Centre http://www.ripe.net/home/mark/ New Projects Group/TTM To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: vmware reads disk on non-sector boundary
On Thu, Sep 26, 2002 at 01:35:43PM -0700, Julian Elischer wrote: Take a look at /sys/compat/linux/linux_stats.c, revision 1.29 date: 2001/01/14 23:33:50; author: joe; state: Exp; lines: +18 -11 Instead of hard coding the major numbers for IDE and SCSI disks look in the device's cdevsw for the D_DISK flag. This fixes the problem with VMWARE not being able to use raw disks. This should have read, Linux uses block devices to access raw drives, but we've got rid of them in -current and so VMWare is having a hard time running off raw partitions. Pretending that disk character device nodes are block devices appears to make VMWare run off raw drives again. but it still doesn't help with partial block reads.. That didn't appear to be a problem with VMWare2. Joe -- As far as the laws of mathematics refer to reality, they are not certain; and as far as they are certain, they do not refer to reality. - Albert Einstein, 1921 msg37102/pgp0.pgp Description: PGP signature
Re: vmware reads disk on non-sector boundary
On Wed, Sep 25, 2002 at 07:41:44PM +0200, Poul-Henning Kamp wrote: The fact that this did work, was it a bug or did this come out due to some other change. The stacktrace from read(2) is below. This hasn't worked for a long time in -current. Long as in 6 months? By looking at the code history it seems so indeed. Do you have an idea what might have 'covered' this though? A fact is that vmware did work up until a few months. I didn't do a binary search yet. That is last resort... Mark -- Mark Santcroos RIPE Network Coordination Centre http://www.ripe.net/home/mark/ New Projects Group/TTM To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: vmware reads disk on non-sector boundary
In message [EMAIL PROTECTED], Mark Santcroos writes: On Wed, Sep 25, 2002 at 07:41:44PM +0200, Poul-Henning Kamp wrote: The fact that this did work, was it a bug or did this come out due to some other change. The stacktrace from read(2) is below. This hasn't worked for a long time in -current. Long as in 6 months? By looking at the code history it seems so indeed. Do you have an idea what might have 'covered' this though? No idea... -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: vmware reads disk on non-sector boundary
On Wed, Sep 25, 2002 at 07:52:17PM +0200, Mark Santcroos wrote: [freebsd-emulation@ bcc'ed] On Wed, Sep 25, 2002 at 07:47:48PM +0200, Mark Santcroos wrote: A fact is that vmware did work up until a few months. I didn't do a binary search yet. That is last resort... Anyone running a -current of several months old and using vmware2? If so, can you please ktrace it and send me the trace. Hmm... I am running VMWARE 2.0.4 build 1142 on a FreeBSD 4.6-STABLE updated and built on Mon Aug 19 16:51:30 PDT 2002. I am not seeing this problem. Tim -- Snail: Tim Pozar / LNS / 1978 45th Ave / San Francisco CA 94116 / USA POTS: +1 415 665 3790 Radio: KC6GNJ / KAE6247 A mass in movement resists change of direction. So does the world oppose a new idea. It takes time to make up the minds to its value and importance. Ignorance, prejudice and inertia of the old retard its early progress. It is discredited by insincere exponents and selfish exploiters. It is attacked and condemned by its enemies. Eventually, though, all barriers are thrown down, and it spreads like fire. This will also prove true of the wireless art. - Nikola Tesla in 1908 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: vmware reads disk on non-sector boundary
vmware used the blocking (b devices) interface to disks that do blocking for you. Some well meaning but misguided individuals removed block devices without providing an alernate way of doing this. It should be possible to do the equivalent of a vn device that accepts misalligned accesses and reblocks them, but I'll leave that to those whose job it is to finish. On Wed, 25 Sep 2002, Mark Santcroos wrote: Vmware2 stopped running from both md and ad devices. Virtual disks still work. It is caused by a read that is not on sector boundary. Should a program be able to read non-sector sized chunks from a raw disk yes or no? What is the desired behaviour? The desired bahaviour is that it works. No programs shouldn't do it, but they sometimes do, particularly LINUX programs.. (e.g. vmware) and the chances that we get linux authors to change is really small. (Particulary vmware who have been particularly stubborn) The fact that this did work, was it a bug or did this come out due to some other change. The stacktrace from read(2) is below. Any input welcome, it's about time that vmware runs again on -current. Mark dscheck(c7528a70,c0c20800,4,c7528a70,c28f0800) at dscheck diskstrategy(c7528a70,10,4,c0c20800,c0c2086c) at diskstrategy+0x7f readdisklabel(c23f4e00,c28f0800,1,c23d4000,c23f4e4c) at readdisklabel+0xb8 dsopen(c2347e00,2000,0,c23d9588,c23d9200) at dsopen+0x1e6 diskopen(c2347e00,1,2000,c23e0cc0,c26c4700) at diskopen+0x15f spec_open(cdac9a2c,cdac9ac8,c027796b,cdac9a2c,c0911c50) at spec_open+0x150 spec_vnoperate(cdac9a2c,c0911c50,1,100,c23e0cc0) at spec_vnoperate+0x18 vn_open_cred(cdac9bcc,cdac9ccc,0,c26c4700,cdac9cb8) at vn_open_cred+0x3eb vn_open(cdac9bcc,cdac9ccc,0,1,cdac9b04) at vn_open+0x29 kern_open(c23e0cc0,8048639,0,1,0) at kern_open+0x1e3 open(c23e0cc0,cdac9d10,c,c23e0cc0,3) at open+0x30 syscall(2f,2f,2f,bfbffae4,bfbffaec) at syscall+0x2ca Xint0x80_syscall() at Xint0x80_syscall+0x1d -- Mark SantcroosRIPE Network Coordination Centre http://www.ripe.net/home/mark/New Projects Group/TTM To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: vmware reads disk on non-sector boundary
On Wed, Sep 25, 2002 at 11:29:12AM -0700, Julian Elischer wrote: vmware used the blocking (b devices) interface to disks that do blocking for you. Some well meaning but misguided individuals removed block devices without providing an alernate way of doing this. It should be possible to do the equivalent of a vn device that accepts misalligned accesses and reblocks them, but I'll leave that to those whose job it is to finish. Hi Julian, That was the background info I was looking for. I might try to do the remapping myself. Thanks Mark -- Mark Santcroos RIPE Network Coordination Centre http://www.ripe.net/home/mark/ New Projects Group/TTM To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: vmware reads disk on non-sector boundary
On Wed, Sep 25, 2002 at 11:29:12AM -0700, Julian Elischer wrote: vmware used the blocking (b devices) interface to disks that do blocking for you. Some well meaning but misguided individuals removed block devices without providing an alernate way of doing this. It should be possible to do the equivalent of a vn device that accepts misalligned accesses and reblocks them, but I'll leave that to those whose job it is to finish. I thought that we hacked around this in the linuxulator 18 months ago by transparently converting block calls into character calls behind the scenes. Either this has been removed or something else is wrong. Joe -- As far as the laws of mathematics refer to reality, they are not certain; and as far as they are certain, they do not refer to reality. - Albert Einstein, 1921 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message