Seems it does not work.
What should be a next step in data recovering?
On 05/30/2012 10:50 PM, Gareth Pye wrote:
Stopping an experimental fsck for an exterimental file system would
probably be the worst idea possible. I'd only think about stopping it
after it had spent many many hours not doing anything*. If it was
working hard after 26 hours I'd just keep working
*This isn't advice to stop it if that is true, just a minimal
condition on me stopping any fsck.
On Thu, May 31, 2012 at 12:02 PM, Maxim Mikheev <mikhmv@xxxxxxxxx
<mailto:mikhmv@xxxxxxxxx>> wrote:
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 <mailto: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
<mailto:majordomo@xxxxxxxxxxxxxxx>
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Gareth Pye
Level 2 Judge, Melbourne, Australia
Australian MTG Forum: mtgau.com <http://mtgau.com/>
gareth@xxxxxxxxxxxxxx <mailto:gareth@xxxxxxxxxxxxxx> -
www.rockpaperdynamite.wordpress.com
<http://www.rockpaperdynamite.wordpress.com/>
"Dear God, I would like to file a bug report"
--
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
