|[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]|
btrfsck --repair running already for 26 hours. Is it have sense to wait more? Thanks On 05/29/2012 07:36 PM, cwillu wrote:
On Tue, May 29, 2012 at 5:24 PM, Maxim Mikheev<mikhmv@xxxxxxxxx> wrote:Thank you for your answer. The system kernel was and now: Linux s0 3.4.0-030400-generic #201205210521 SMP Mon May 21 09:22:02 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux the raid was created by: mkfs.btrfs /dev/sdb /dev/sdc /dev/sdd /dev/sde /dev/sdf Disk are connected through RocketRaid 2670. for mounting I used line in fstab: UUID=c9776e19-37eb-4f9c-bd6b-04e8dde97682 /tank btrfs defaults,compress=lzo 0 1 On machine was running several Virtual machines. Only one was actively using disks. VM has active several threads: 1. 2 threads reading big files (50GB each) 2. reading from 50 files and writing one big file 3. The kernel panic happens when I run another program with 30 threads of reading/writing of small files. Virtual Machine accessed to underline btrfs through 9-p file system which actively used xattr. After reboot system was in this stage. I hope that btrfsck --repair will not make it worse, It is now running.**twitch** Well, I also hope it won't make it worse. Do not cancel it now, let it finish (aborting it will make things worse), but I suggest waiting until a few more people have weighed in before attempting anything beyond that.
-- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html