LVM2 behaving erratically
Denys Vlasenko
vda.linux at googlemail.com
Tue Feb 17 02:09:05 UTC 2009
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
More information about the uClibc
mailing list