On Monday 16 February 2009 23:21, Stefan Monnier wrote: > I'm trying to get LVM2 installed on a small MIPS machine using uClibc > and am seeing some really odd non-deterministic behavior. > > I have a chroot of Debian on that machine as well, where LVM2 works > just fine. The main difference between the two seems to be > glibc-vs-uClibc, so I suspect the problem might be linked to uClibc. > > After adding debug statements to LVM2's code at various places, I got to > the point where I see that when `lvm' reads some blocks from the various > block devices (e.g. to try and figure out which devices contain LVM > partition), it doesn't always get the same result. > > More specifically, I see things like: a call to "read" on the same > device, at the same offset (lseek is called right before) and of the > same number of bytes, returning different results (if I sum up the > returned bytes, the sum is different). > > Now, I'm pretty uClibc's "read" function works, since otherwise I'd have > had much more serious problems earlier, so I'm kind of lost. > I did make sure that the device's underlying data doesn't change. > So it's really a problem where "read" seems to return garbage. > > The only "unusual" thing that springs to mind is that the file > descriptor is opened with O_DIRECT. But all the laignment constraints > seem to be satisfied (and indeed, I don't get any EINVAL error, not any > other error for that matter).
[Why on earth do they use O_DIRECT there??] Do you see the same in a small, self contined test program? Does it work ofay when you remove O_DIRECT bit from open? -- vda _______________________________________________ uClibc mailing list [email protected] http://lists.busybox.net/mailman/listinfo/uclibc
