András Imre wrote:
> rc10 is not available for me with aptitude. I had to compile and install
> it manually. No problems. The outputs are the same, except
> for the following 2 additional/1 changed lines for dmraid -ay -vvv -d:
> ...
> device-mapper: dm-linear: Device lookup failed
> device-mapper: error adding target to table
This sort of error is sometimes caused by mismatched dmraid /
devicemapper version. Not sure that this specific one is though -
it's a guess.
It's irritating that a version mismatch can occur, and that (fx.)
dmraid cannot check that the devicemapper version is usable, but
that's how it is - you have to check for yourself.
So far, in my experience, the devicemapper is not trying to stay
backwards compatible wrt. it's binary interface. That means that even
versions of the devicemapper library that is newer than the version at
the time of dmraid's release may not work correctly.
("May not work correctly" usually means doesn't work at all, but who
knows, if they decide to switch two parameters to a function one day,
it could mean "trash you data". I'm not particularly worried about
the scenario, I'm just saying that the way things are now, in theory
it could happen.)
If I were you I'd try the newest version of devicemapper and see if
the errors go away. Then I'd try the version that was available when
the version of dmraid that you're using was announced.
But then again, maybe I'm wrong on the entire version mismatch being
the reason for the problem, someone else might have a much better idea
of what the problem is.
I think that JBOD (SPAN to be unambiguous) configurations are much
less tested than RAID0. The advantage of SPAN is that you're much
better set if you need to recover something after one of the disks
fail, but most people probably prefer more performance and therefore
go with RAID0. SPAN being somewhat more untested, it could be that
dmraid is giving the devicemapper wrong parameters for the table
setup. What do I know, haven't tested myself - throwing out a couple
of wild guesses here :-)...
> ...
> ERROR: dos: reading /dev/mapper/via_bdafghaihj[No such file or directory]
That's ok, that's a followup error meaning that partition scanning
cannot be done on the new, assembled (virtual) disk.
Since the assembled disk probably consist of 0 individual (real) disks
(you can that on the "adding target failed" error msg), there's not
much chance of a partition scan succeeding.
Since your partition scan succeeded with rc9, this is now even worse :-).
With rc9, at least something was added to the table (use dmsetup to
show what and how much).
> The second line also appears in syslog. Checked backwards, and found that
> this appeared for rc9 also, just was not displayed on console. Not too much
> difference, I guess.
Ok, so at least one of the disks was not added correctly with rc9, but
partition scanning did succeed.
If I should guess, I'd say that the first disk was added correctly
with rc9 (and none of the disks with rc10).
I'd recommend upgrading the devicemapper and testing again as the
first thing to do.
> Is there anything else I should be looking for?
Please include the output of 'dmsetup table' when doing your next test :-).
> Just curious: what kind of live cd would you make if needed?
Whatever's easiest - I'd probably take a basic Slax image, add a
developer module containing GCC and MAKE, boot it, download
devicemapper + dmraid, compile and install both and then make a new
module out of the resulting binaries using the excellent
Slax-module-making tools..
> I dont have. I still only have /dev/mapper/.
> After dmsetup I also have /dev/mapper/via_bdafghaihj, but no numbered ones.
Ok. Unfortunately you'll probably find that
/dev/mapper/via_bdafghaihj is zero bytes "long". The virtual disk
device being created doesn't actually mean that things are working,
since it can be made up of 0 targets.
> > What does "fdisk -l /dev/mapper/via_bdafghaihj" say?
>
> Lists nothing. (Dir exists.)
Ok, hmm.
Guess that's what fdisk does when it encounters a zero byte device.
There's an IOCTL to get the LBA size of the devicemapper device that
fdisk uses to check the size of the device, and I guess you could call
that function yourself with a C app and retrieve the size and check if
it's zero. But then again you could also just use 'dmsetup table'
:-).
> After install, dmsetup produces the following output:
>
> ----------------------------------------------------------------------
> # dmsetup status
> via_bdafghaihj:
> ----------------------------------------------------------------------
> # dmsetup ls
> via_bdafghaihj (254, 0)
> ----------------------------------------------------------------------
> # dmsetup info
> Name: via_bdafghaihj
> State: ACTIVE
> Tables present: None
> Open count: 0
> Event number: 0
> Major, minor: 254, 0
> Number of targets: 0
The above line doesn't look too good, it should say 2.
> That's why I have sda{1,2,3}. Is there a chance that some
> partition/metadata info for sda3 is actually spanned onto
> the second physical disk?
Partitions 1, 2, 3 and 4 are what's called 'primary' partitions,
meaning that the partition metadata lies within the MBR, which is at
the beginning of the first disk.
> That can be a reason for sda3 ntfs mount failure...
Mots of the data for the ntfs partition is beyond the length of the
sda device. I think ntfs mount fails because it cannot find it's
data. It probably tries since the sda3 device looks healthy to it,
but once it starts reading the filesystem metadata, it'll hit a 'read
beyond end of device' error. If that's what you mean, then yes :-).
> But before that, I'd like to see it working.
Out of curiosity, what's the purpose of the system?
> Thanks for the tips and questions. Hope you will have more.
It's mostly guesswork but hope it's useful anyway :)
_______________________________________________
Ataraid-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/ataraid-list
