Re: Problem with 5disk RAID5 array - two drives lost
On Sun, 2006-04-23 at 17:17 -0700, Tim Bostrom wrote: > I bought two extra 250GB drives - I'll try using dd_rescue as > recommended and see if I can get a "good" copy of hdf online. You might want to use dd_rhelp: http://www.kalysto.org/utilities/dd_rhelp/index.en.html -Arthur - To unsubscribe from this list: send the line "unsubscribe linux-raid" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
proactive raid5 disk replacement success (using bitmap + raid1)
i had a disk in a raid5 which i wanted to clone onto the hot spare... without going offline and without long periods without redundancy. a few folks have discussed using bitmaps and temporary (superblockless) raid1 mappings to do this... i'm not sure anyone has tried / reported success though. this is my success report. setup info: - kernel version 2.6.16.9 (as packaged by debian) - mdadm version 2.4.1 - /dev/md4 is the raid5 - /dev/sde1 is the disk in md4 i want to clone from - /dev/sdh1 is the hot spare from md4, and is the clone target - /dev/md5 is an unused md device name here are the exact commands i issued: mdadm -Gb internal --bitmap-chunk=1024 /dev/md4 mdadm /dev/md4 -r /dev/sdh1 mdadm /dev/md4 -f /dev/sde1 -r /dev/sde1 mdadm --build /dev/md5 -ayes --level=1 --raid-devices=2 /dev/sde1 missing mdadm /dev/md4 --re-add /dev/md5 mdadm /dev/md5 -a /dev/sdh1 ... wait a few hours for md5 resync... mdadm /dev/md4 -f /dev/md5 -r /dev/md5 mdadm --stop /dev/md5 mdadm /dev/md4 --re-add /dev/sdh1 mdadm --zero-superblock /dev/sde1 mdadm /dev/md4 -a /dev/sde1 this sort of thing shouldn't be hard to script :) the only times i was without full redundancy was briefly between the "-r" and "--re-add" commands... and with bitmap support the raid5 resync for each of those --re-adds was essentially zero. thanks Neil (and others)! -dean p.s. it's absolutely necessary to use "--build" for the temporary raid1 ... if you use --create mdadm will rightfully tell you it's already a raid component and if you --force it then you'll trash the raid5 superblock and it won't fit into the raid5 any more... - To unsubscribe from this list: send the line "unsubscribe linux-raid" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Problem with 5disk RAID5 array - two drives lost
First let me say - thank you for responding. I'm still trying to
figure out this problem.
On Apr 21, 2006, at 8:54 PM Apr 21, 2006, Molle Bestefich wrote:
Tim Bostrom wrote:
It appears that /dev/hdf1 failed this past week and /dev/hdh1
failed back in February.
An obvious question would be, how much have you been altering the
contents of the array since February?
This is a video backup drive for my MythTV system. I just backup old
TV shows and movies from my system. There's maybe 3-4 GB of data
that's been stored there since February and no other data's been
moved or deleted. Pretty much when something is backed up here, it
stays. I'm willing to lose the February - April data.
hdf: dma_intr: error=0x40 { UncorrectableError }, LBAsect=6720
Actually, there's a lot of sequential sector numbers in the output
you posted.
I think it's unusual for a drive to develop that many bad blocks in
a row.
I could be wrong, and it could be a head crash or something (have you
been moving the system around much?).
But if I had to guess, I'd say that there's a real likelihood that
it's a loose cable or a controller problem or a driver issue.
Could you try and run:
# dd if=/dev/hdf of=/dev/null bs=1M count=100 skip=1234567
You can play around with different random numbers instead of 1234567.
If it craps out *immediately*, then I'd say it's a cable problem or
so, and not a problem with what's on the platters.
Tried running this. It doesn't crap out immediately. Goes along,
but I see a bunch of the {Uncorrectable Error} {Drive Ready Seek
Complete} errors in dmesg that I posted before. I see these messages
in dmesg when I run the above command.
I bought two extra 250GB drives - I'll try using dd_rescue as
recommended and see if I can get a "good" copy of hdf online.
No, get the array running first, then fix the filesystem.
You can initiate array checks and repairs like this:
# cd /sys/block/md0/md/
# echo check > sync_action
or
# echo repair > sync_action
-
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Recovery speed at 1MB/s/device, unable to change
(resend, prev post missed the list)
Neil Brown wrote:
> On Monday April 24, [EMAIL PROTECTED] wrote:
>
>># mdadm --grow /dev/md_d1 --raid-devices=3 --backup-file backupfile
>>mdadm: Need to backup 128K of critical section..
>>mdadm: /dev/md_d1: Cannot get array details from sysfs
>>
>>Strace shows that it's trying to access
>>"/sys/block/md_d4/md/component_size".
>>
>>Why is this?
>
>
> Because I didn't test my code properly :-(
>
> Following patch should fix it.
>
It appears you missed another occurrence (patch attached).
However, it got stuck after
mdadm: Need to backup 128K of critical section..
I did ctrl-c, and according to /proc/mdstat it was successfully
reshaped, nor can I restart the reshape.
But "umount /mnt/test" (/mnt/test is where /dev/md_d1p1 is mounted)
blocks, and this time it becomes unkillable.
/proc/mdstat reports:
md_d1 : active raid5 loop1[1] loop0[0]
4992 blocks level 5, 64k chunk, algorithm 2 [3/2] [UU_]
--
Anssi Hannula
--- sysfs.c.old 2006-04-24 01:24:09.0 +0300
+++ sysfs.c 2006-04-24 01:33:48.0 +0300
@@ -69,7 +69,7 @@
sprintf(sra->name, "md%d", minor(stb.st_rdev));
else
sprintf(sra->name, "md_d%d",
-minor(stb.st_rdev)/16);
+minor(stb.st_rdev)/64);
} else {
if (devnum >= 0)
sprintf(sra->name, "md%d", devnum);
Re: Recovery speed at 1MB/s/device, unable to change
(sorry, prev post missed the list) Neil Brown wrote: > On Monday April 24, [EMAIL PROTECTED] wrote: > >># mdadm --grow /dev/md_d1 --raid-devices=3 --backup-file backupfile >>mdadm: Need to backup 128K of critical section.. >>mdadm: /dev/md_d1: Cannot get array details from sysfs >> >>Strace shows that it's trying to access >>"/sys/block/md_d4/md/component_size". >> >>Why is this? > > > Because I didn't test my code properly :-( > > Following patch should fix it. Okay, will test. > Re: the recovery speed problem: I would try dding from one drive to > the other and see what sort of speed you get then: > dd if=/dev/sda of=/dev/sdb bs=1024k count=1000 > or something like that. # export LANGUAGE=C; export LANG=C; export LC_ALL=C; date; dd if=/dev/sda skip=2 of=/dev/sdb bs=1024k count=1000; date Mon Apr 24 01:14:48 EEST 2006 1000+0 records in 1000+0 records out Mon Apr 24 01:15:42 EEST 2006 So the speed is about 20MB/s. -- Anssi Hannula - To unsubscribe from this list: send the line "unsubscribe linux-raid" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: EVMS causing problems with mdadm?
On Mon, Apr 24, 2006 at 07:48:00AM +1000, Neil Brown wrote: On Sunday April 23, [EMAIL PROTECTED] wrote: Did my latest updates for my Kubuntu (Ubuntu KDE variant) this morning, and noticed that EVMS has now "taken control" of my RAID array. Didn't think much about it until I tried to make a RAID-1 array with two disks I've just added to the system. Trying to do a create verbose tells me that device /dev/md1 (or 2 or 3 - I tried a couple just to see) doesn't exist. And in fact, there are no block devices listed beyond md0. Sounds like udev is in use rather than a static /dev. Add '--auto=md' to the mdadm command line, and it will create the devices for you. Or --auto=part if you want partitioned arrays. See man page for more details. I suspect this might need to be come the default in another year or so i was tkinking about stat()ing "/dev/.udev" and automatically enabling --auto if found WDYT? L. -- Luca Berra -- [EMAIL PROTECTED] Communication Media & Services S.r.l. /"\ \ / ASCII RIBBON CAMPAIGN XAGAINST HTML MAIL / \ - To unsubscribe from this list: send the line "unsubscribe linux-raid" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Recovery speed at 1MB/s/device, unable to change
On Monday April 24, [EMAIL PROTECTED] wrote: > # mdadm --grow /dev/md_d1 --raid-devices=3 --backup-file backupfile > mdadm: Need to backup 128K of critical section.. > mdadm: /dev/md_d1: Cannot get array details from sysfs > > Strace shows that it's trying to access > "/sys/block/md_d4/md/component_size". > > Why is this? Because I didn't test my code properly :-( Following patch should fix it. Re: the recovery speed problem: I would try dding from one drive to the other and see what sort of speed you get then: dd if=/dev/sda of=/dev/sdb bs=1024k count=1000 or something like that. Thanks, NeilBrown Signed-off-by: Neil Brown <[EMAIL PROTECTED]> ### Diffstat output ./sysfs.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff ./sysfs.c~current~ ./sysfs.c --- ./sysfs.c~current~ 2006-03-14 15:33:12.0 +1100 +++ ./sysfs.c 2006-04-24 07:56:56.0 +1000 @@ -206,7 +206,7 @@ unsigned long long get_component_size(in minor(stb.st_rdev)); else sprintf(fname, "/sys/block/md_d%d/md/component_size", - minor(stb.st_rdev)/16); + minor(stb.st_rdev)/64); fd = open(fname, O_RDONLY); if (fd < 0) return 0; - To unsubscribe from this list: send the line "unsubscribe linux-raid" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: EVMS causing problems with mdadm?
On Sunday April 23, [EMAIL PROTECTED] wrote: > Did my latest updates for my Kubuntu (Ubuntu KDE variant) this > morning, and noticed that EVMS has now "taken control" of my RAID > array. Didn't think much about it until I tried to make a RAID-1 array > with two disks I've just added to the system. Trying to do a create > verbose tells me that device /dev/md1 (or 2 or 3 - I tried a couple > just to see) doesn't exist. And in fact, there are no block devices > listed beyond md0. Sounds like udev is in use rather than a static /dev. Add '--auto=md' to the mdadm command line, and it will create the devices for you. Or --auto=part if you want partitioned arrays. See man page for more details. I suspect this might need to be come the default in another year or so NeilBrown > > Trying to go into EVMS to create a new Volume brings up the screen for > doing so, but doesn't actually let you create a new one. > > Any suggestion of what I might be doing wrong, or is this a bug I > should be reporting to the Ubuntu folks? > - > To unsubscribe from this list: send the line "unsubscribe linux-raid" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html - To unsubscribe from this list: send the line "unsubscribe linux-raid" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: to be or not to be...
On Sunday April 23, [EMAIL PROTECTED] wrote: > Hi all, > to make a long story very very shorty: > a) I create /dev/md1, kernel latest rc-2-git4 and mdadm-2.4.1.tgz, > with this command: > /root/mdadm -Cv /dev/.static/dev/.static/dev/.static/dev/md1 \ > --bitmap-chunk=1024 --chunk=256 --assume-clean --bitmap=internal > \ ^^ > -l5 -n5 /dev/hda2 /dev/hdb2 /dev/hde2 /dev/hdf2 missing > From the man page: --assume-clean Tell mdadm that the array pre-existed and is known to be clean. It can be useful when trying to recover from a major failure as you can be sure that no data will be affected unless you actu- ally write to the array. It can also be used when creating a RAID1 or RAID10 if you want to avoid the initial resync, however this practice - while normally safe - is not recommended. Use ^^^ this ony if you really know what you are doing. ^^ So presumably you know what you are doing, and I wonder why you bother to ask us :-) Ofcourse, if you don't know what you are doing, then I suggest dropping the --assume-clean. In correct use of this flag can lead to data corruption. This is particularly true if your array goes degraded, but is also true while your array isn't degraded. In this case it is (I think) very unusual and may not be the cause of your corruption, but you should avoid using the flag anyway. > b) dm-encrypt /dev/md1 > > c) create fs with: > mkfs.ext3 -O dir_index -L 'tritone' -i 256000 /dev/mapper/raidone > > d) export it via nfs (mounting /dev/mapper/raidone as ext2) Why not ext3? > > e) start to cp-ing files > > f) after 1 TB of written data, with no problem/warning, one of the > not-in-raid-array HD freeze This could signal a bad controller. If it does, then you cannot trust any drives. NeilBrown - To unsubscribe from this list: send the line "unsubscribe linux-raid" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Recovery speed at 1MB/s/device, unable to change
Anssi Hannula wrote: > The speed is only 2000K/sec, even after I set: > --- > # cat /proc/sys/dev/raid/speed_limit_min > 1 > # cat /proc/sys/dev/raid/speed_limit_max > 40 > --- > > The system is about 90% idle, so there should be more bandwidth. > > --- > # cat /proc/version > Linux version 2.6.17-rc2-git4 ([EMAIL PROTECTED]) (gcc version 4.0.1 > (4.0.1-5mdk for Mandriva Linux release 2006.0)) #1 Sun Apr 23 00:56:30 > EEST 2006 > --- Hmm... I don't know if this is related, but something seems to be really wrong. I run the following set of commands: # dd if=/dev/zero of=ohase count=5K # dd if=/dev/zero of=ohase2 count=5K # losetup /dev/loop0 ohase # losetup /dev/loop1 ohase2 # mdadm --create /dev/md_d1 -ap --level=5 --raid-devices=2 /dev/loop0 missing # fdisk /dev/md_d1 (created one partition) # mkfs.ext3 /dev/md_d1p1 # mount /dev/md_d1p1 /mnt/test # echo jopajoo > /mnt/iso/test # mdadm --manage /dev/md_d1 --add /dev/loop1 # mdadm --grow /dev/md_d1 --raid-devices=3 --backup-file backupfile mdadm: Need to backup 128K of critical section.. mdadm: /dev/md_d1: Cannot get array details from sysfs Strace shows that it's trying to access "/sys/block/md_d4/md/component_size". Why is this? -- Anssi Hannula - To unsubscribe from this list: send the line "unsubscribe linux-raid" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Recovery speed at 1MB/s/device, unable to change
I created a raid array: --- # mdadm --create /dev/md_d0 -ap --level=5 --raid-devices=2 \ /dev/sda1 missing --- Then partitioned it: --- # LANGUAGE=C fdisk -l /dev/md_d0 Disk /dev/md_d0: 250.0 GB, 250056605696 bytes 2 heads, 4 sectors/track, 61048976 cylinders Units = cylinders of 8 * 512 = 4096 bytes Device Boot Start End Blocks Id System /dev/md_d0p1 161048976 244195902 83 Linux --- Then made a ext3 filesystem in /dev/md_d0p1 with mke2fs. Then I added another device: --- # mdadm --manage /dev/md_d0 --add /dev/sdb1 --- Currently status is: --- # cat /proc/mdstat Personalities : [raid0] [raid5] [raid4] md_d0 : active raid5 sdb1[2] sda1[0] 244195904 blocks level 5, 64k chunk, algorithm 2 [2/1] [U_] [>] recovery = 1.0% (2588800/244195904) finish=2100.4min speed=1916K/sec unused devices: --- The speed is only 2000K/sec, even after I set: --- # cat /proc/sys/dev/raid/speed_limit_min 1 # cat /proc/sys/dev/raid/speed_limit_max 40 --- The system is about 90% idle, so there should be more bandwidth. --- # cat /proc/version Linux version 2.6.17-rc2-git4 ([EMAIL PROTECTED]) (gcc version 4.0.1 (4.0.1-5mdk for Mandriva Linux release 2006.0)) #1 Sun Apr 23 00:56:30 EEST 2006 --- Any tips? -- Anssi Hannula - To unsubscribe from this list: send the line "unsubscribe linux-raid" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: disks becoming slow but not explicitly failing anyone?
> I've seen a lot of cheap disks say (generally deep in the data sheet > that's only available online after much searching and that nobody ever > reads) that they are only reliable if used for a maximum of twelve hours > a day, or 90 hours a week, or something of that nature. Even server I haven't, and I read lots of specs. they _will_ sometimes say that non-enterprise drives are "intended" or "designed" for a 8x5 desktop-like usage pattern. to the normal way of thinking about reliability, this would simply mean a factor of 4.2x lower reliability - say from 1M to 250K hours MTBF. that's still many times lower rate of failure than power supplies or fans. > It still stuns me that anyone would ever voluntarily buy drives that > can't be left switched on (which is perhaps why the manufacturers hide I've definitely never seen any spec that stated that the drive had to be switched off. the issue is really just "what is the designed duty-cycle?" I run a number of servers which are used as compute clusters. load is definitely 24x7, since my users always keep the queues full. but the servers are not maxed out 24x7, and do work quite nicely with desktop drives for years at a time. it's certainly also significant that these are in a decent machineroom environment. it's unfortunate that disk vendors aren't more forthcoming with their drive stats. for instance, it's obvious that "wear" in MTBF terms would depend nonlinearly on the duty cycle. it's important for a customer to know where that curve bends, and to try to stay in the low-wear zone. similarly, disk specs often just give a max operating temperature (often 60C!), which is almost disingenuous, since temperature has a superlinear effect on reliability. a system designer needs to evaluate the expected duty cycle when choosing disks, as well as many other factors which are probably more important. for instance, an earlier thread concerned a vast amount of read traffic to disks resulting from atime updates. obviously, just mounting noatime will improve the system's reliability. providing a bit more memory on a fileserver to cache and eliminate IOs is another great way to help out. simply using more disks also decreases the load per disk, though this is clearly only a win if it's the difference in staying out of the disks "duty-cycle danger zone" (since more disks divide system MTBF). regards, mark hahn. - To unsubscribe from this list: send the line "unsubscribe linux-raid" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: replace disk in raid5 without linux noticing?
Carlos Carvalho wrote on Sat, Apr 22, 2006 at 02:48:23PM -0300: > Martin Cracauer (cracauer@cons.org) wrote on 22 April 2006 11:08: > >> stop the array > >> dd warning disk => new one > >> remove warning disk > >> assemble the array again with the new disk > >> > >> The inconvenience is that you don't have the array during the copy. > > > >Stopping the array and restarting it as readonly will give you access > >to the data while that copy is in progress. > > Yes but then you could just switch it to read-only without stopping. I believe that would be fine to do the whole operation. Filesystem read-only, then md read-only, copy disk, then you need to unmount and stop the md to restart it with the new disk. If the final disk change involves a powerdown and putting the new disk on the physical interface that the old one was on it should be transparent. %% BTW, last time I tested a Linux software RAID-5 by ripping out an active disk I noticed that while the filesystem stayed up and usable, a currently ongoing system call would not return and block forever. Is that a know behaviour? Martin -- %%% Martin Cracauerhttp://www.cons.org/cracauer/ FreeBSD - where you want to go, today. http://www.freebsd.org/ - To unsubscribe from this list: send the line "unsubscribe linux-raid" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
EVMS causing problems with mdadm?
Did my latest updates for my Kubuntu (Ubuntu KDE variant) this morning, and noticed that EVMS has now "taken control" of my RAID array. Didn't think much about it until I tried to make a RAID-1 array with two disks I've just added to the system. Trying to do a create verbose tells me that device /dev/md1 (or 2 or 3 - I tried a couple just to see) doesn't exist. And in fact, there are no block devices listed beyond md0. Trying to go into EVMS to create a new Volume brings up the screen for doing so, but doesn't actually let you create a new one. Any suggestion of what I might be doing wrong, or is this a bug I should be reporting to the Ubuntu folks? - To unsubscribe from this list: send the line "unsubscribe linux-raid" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: to be or not to be...
gelma wrote: > first run: lot of strange errors report about impossible i_size > values, duplicated blocks, and so on You mention only filesystem errors, no block device related errors. In this case, I'd say that it's more likely that dm-crypt is to blame rather than MD. I think you should try the dm-devel mailing list. Posting a complete log of everything that has happened would probably be a good thing. I have no experience with dm-crypt, but I do have experience with another dm target (dm-snapshot), which iss very good at destroying my data. If you want a stable solution for encrypting your files, I can recommend loop-aes. loop-aes has very well thought-through security, the docs are concise but have wide coverage, it has good backwards compatibility - probably not your biggest concern right now, but it is *very* nice to know that your data is accessible, in the future as well as now - etc.. I've been using it for a couple of years now, since the 2.2 or 2.4 days (can't remember), and I've had nothing short of an absolutely *brilliant* experience with it. Enough propaganda for now, hope that you get your problem solved :-). - To unsubscribe from this list: send the line "unsubscribe linux-raid" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: disks becoming slow but not explicitly failing anyone?
On 23 Apr 2006, Mark Hahn said: > some people claim that if you put a normal (desktop) > drive into a 24x7 server (with real round-the-clock load), you should > expect failures quite promptly. I'm inclined to believe that with > MTBF's upwards of 1M hour, vendors would not claim a 3-5yr warranty > unless the actual failure rate was low, even if only running 8/24. I've seen a lot of cheap disks say (generally deep in the data sheet that's only available online after much searching and that nobody ever reads) that they are only reliable if used for a maximum of twelve hours a day, or 90 hours a week, or something of that nature. Even server disks generally seem to say something like that, but the figure given is more like `168 hours a week', i.e., constant use. It still stuns me that anyone would ever voluntarily buy drives that can't be left switched on (which is perhaps why the manufacturers hide the info in such an obscure place), and I don't know what might go wrong if you use the disk `too much': overheating? But still it seems that there are crappy disks out there with very silly limits on the time they can safely be used for. (But this *is* the RAID list: we know that disks suck, right?) -- `On a scale of 1-10, X's "brokenness rating" is 1.1, but that's only because bringing Windows into the picture rescaled "brokenness" by a factor of 10.' --- Peter da Silva - To unsubscribe from this list: send the line "unsubscribe linux-raid" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
to be or not to be...
Hi all, to make a long story very very shorty: a) I create /dev/md1, kernel latest rc-2-git4 and mdadm-2.4.1.tgz, with this command: /root/mdadm -Cv /dev/.static/dev/.static/dev/.static/dev/md1 --bitmap-chunk=1024 --chunk=256 --assume-clean --bitmap=internal -l5 -n5 /dev/hda2 /dev/hdb2 /dev/hde2 /dev/hdf2 missing b) dm-encrypt /dev/md1 c) create fs with: mkfs.ext3 -O dir_index -L 'tritone' -i 256000 /dev/mapper/raidone d) export it via nfs (mounting /dev/mapper/raidone as ext2) e) start to cp-ing files f) after 1 TB of written data, with no problem/warning, one of the not-in-raid-array HD freeze g) reboot, check with: fsck -C -D -y /dev/mapper/raidone a) first run: lot of strange errors report about impossible i_size values, duplicated blocks, and so on, but it ends without complain, saying everything is fixed. b) mount it (as ext3), everything, at first glance, seems good (I will check checksum tomorrow) as number/size/filename/directory place of files. In /lost+found some files, but nothing "real". I mean, special files/devices, that never were on that fs, with giga/tera size (holes, of course), with chattr bits randomly setted. when I try to remove them I've got a kernel complain about offset in dir /lost+found. c) fsck again, after everything is fine Now the cloning from old storage is going on, and now I'm wondering if "--assume-clean" could be the reason of what happens. btw, hardware passed usual test (memtest, cpuburn, ecc). thanks a lot for your time and sorry for my terrible english, gelma - To unsubscribe from this list: send the line "unsubscribe linux-raid" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
