Option -i was helpful.
Some date was restored.
during restoring some files I got message ret is -3. This files has 0
size.
Can anyone tell me what is code -3 mean. Is it recoverable?
So basically data is on harddrives but not completely available.
the questions is: Is it possible to btrfs
Hi Everyone,
Is it possible to extract specific file instead of downloading everything?
Thanks
On 06/06/2012 12:25 PM, Maxim Mikheev wrote:
Option -i was helpful.
Some date was restored.
during restoring some files I got message ret is -3. This files has
0 size.
Can anyone tell me what is
Am Montag, 4. Juni 2012 schrieb Hugo Mills:
On Mon, Jun 04, 2012 at 12:24:05PM -0400, Maxim Mikheev wrote:
I run through all potential tree roots. It gave me everytime
messages like these:
parent transid verify failed on 3405159735296 wanted 9096 found 5263
parent transid verify failed
Am Dienstag, 5. Juni 2012 schrieb Martin Steigerwald:
Am Montag, 4. Juni 2012 schrieb Hugo Mills:
On Mon, Jun 04, 2012 at 12:24:05PM -0400, Maxim Mikheev wrote:
I run through all potential tree roots. It gave me everytime
messages like these:
parent transid verify failed on
Am Montag, 4. Juni 2012 schrieb Maxim Mikheev:
--super works but my root tree 2 has many errors too.
What can I do next?
Have a data recovery company try to physically recover the bad harddisk to
a good one and then try to mount BTRFS again and hope that your previous
attempts to repair the
Hallo, Martin,
Du meintest am 05.06.12:
--super works but my root tree 2 has many errors too.
What can I do next?
Have a data recovery company try to physically recover the bad
harddisk to a good one
About 1 year ago I asked Kroll-Ontrack. They told me they couldn't (yet)
recover btrfs.
On 04.06.2012 04:59, Liu Bo wrote:
On 06/04/2012 10:18 AM, Maxim Mikheev wrote:
Hi Liu,
1) all of them not working (see dmesg at the end)
2)
max@s0:~$ sudo btrfs scrub start /dev/sdb
ERROR: getting dev info for scrub failed: Inappropriate ioctl for device
max@s0:~$ sudo btrfs scrub start
How can I mount it at the first?
On 06/04/2012 04:18 AM, Arne Jansen wrote:
On 04.06.2012 04:59, Liu Bo wrote:
On 06/04/2012 10:18 AM, Maxim Mikheev wrote:
Hi Liu,
1) all of them not working (see dmesg at the end)
2)
max@s0:~$ sudo btrfs scrub start /dev/sdb
ERROR: getting dev info for
On 04.06.2012 13:30, Maxim Mikheev wrote:
How can I mount it at the first?
Let me state it differently: If you can't mount it, you can't scrub it.
On 06/04/2012 04:18 AM, Arne Jansen wrote:
On 04.06.2012 04:59, Liu Bo wrote:
On 06/04/2012 10:18 AM, Maxim Mikheev wrote:
Hi Liu,
1) all
Hi Arne,
Can you advice how can I recover data?
I tried almost everything what I found on https://btrfs.wiki.kernel.org
/btrfs-restore restored some files but it is not what was stored.
I have seen this command
--
In case of a corrupted
On Mon, Jun 04, 2012 at 08:01:32AM -0400, Maxim Mikheev wrote:
Thank you for helping.
I'm not sure I can be of much help, but there were a few things
missing from the earlier conversation that I wanted to check the
details of.
~$ uname -a
Linux s0 3.4.0-030400-generic #201205210521 SMP Mon
adding -v, as an example:
sudo btrfs-find-root -v -v -v -v -v /dev/sdb
didn't change output at all.
On 06/04/2012 08:11 AM, Hugo Mills wrote:
On Mon, Jun 04, 2012 at 08:01:32AM -0400, Maxim Mikheev wrote:
Thank you for helping.
I'm not sure I can be of much help, but there were a few
[trimmed Arne Jan from cc by request]
On Mon, Jun 04, 2012 at 08:28:22AM -0400, Maxim Mikheev wrote:
adding -v, as an example:
sudo btrfs-find-root -v -v -v -v -v /dev/sdb
didn't change output at all.
OK, then all I can suggest is what I said below -- work through the
potential tree
I used only one volume.
I will work through your suggestion.
Is any other options here?
On 06/04/2012 08:34 AM, Hugo Mills wrote:
[trimmed Arne Jan from cc by request]
On Mon, Jun 04, 2012 at 08:28:22AM -0400, Maxim Mikheev wrote:
adding -v, as an example:
sudo btrfs-find-root -v -v -v -v
On Mon, Jun 04, 2012 at 07:43:40AM -0400, Maxim Mikheev wrote:
alternate copy you wish to use. In the following example we ask for
using the superblock copy #2 of /dev/sda7:
# ./btrfsck -s 2 /dev/sd7
-
but it gave me:
$ sudo btrfsck -s 2 /dev/sdb
I run through all potential tree roots. It gave me everytime messages
like these:
parent transid verify failed on 3405159735296 wanted 9096 found 5263
parent transid verify failed on 3405159735296 wanted 9096 found 5263
parent transid verify failed on 3405159735296 wanted 9096 found 5263
parent
--super works but my root tree 2 has many errors too.
What can I do next?
Thanks
On 06/04/2012 10:54 AM, Ryan C. Underwood wrote:
On Mon, Jun 04, 2012 at 07:43:40AM -0400, Maxim Mikheev wrote:
alternate copy you wish to use. In the following example we ask for
using the superblock copy #2 of
On Mon, Jun 04, 2012 at 06:04:22PM +0100, Hugo Mills wrote:
I'm out of ideas.
... but that's not to say that someone else may have some ideas. I
wouldn't get your hopes up too much, though.
At this point, though, you're probably looking at somebody writing
custom code to scan the FS
If he has it in a RAID 1, could he manually fail the bad disk and try
it from there? Obviously this could be harmful, so a dd copy would be
a VERY good idea(truthfully, that should have been the first thing
that was done).
Michael
On Mon, Jun 4, 2012 at 12:09 PM, Hugo Mills h...@carfax.org.uk
It was a RAID0 unfortunately.
On 06/04/2012 02:02 PM, Michael wrote:
If he has it in a RAID 1, could he manually fail the bad disk and try
it from there? Obviously this could be harmful, so a dd copy would be
a VERY good idea(truthfully, that should have been the first thing
that was done).
Below is what you used? So you have RAID 0 for data, RAID 1 for
metadata. This doesn't help any, but a point of info.
# Create a filesystem across four drives (metadata mirrored, data striped)
mkfs.btrfs /dev/sdb /dev/sdc /dev/sdd /dev/sde
Just to make sure I understand correctly: This FS with
On 06/02/2012 09:43 PM, Maxim Mikheev wrote:
Repair was not helpful.
Is any other ways to get access to data?
Please help
Hi Maxim,
Besides btrfsck --repair, we also have a recovery mount option to deal with
your situation,
maybe you can try mount xxx -o recovery and see if it
Hi Liu,
thanks for advice. I tried it before btrfsck. results are here:
max@s0:~$ sudo mount /tank -o recovery
[sudo] password for max:
mount: wrong fs type, bad option, bad superblock on /dev/sdf,
missing codepage or helper program, or other error
In some cases useful info is
On 06/04/2012 09:43 AM, Maxim Mikheev wrote:
Hi Liu,
thanks for advice. I tried it before btrfsck. results are here:
max@s0:~$ sudo mount /tank -o recovery
[sudo] password for max:
mount: wrong fs type, bad option, bad superblock on /dev/sdf,
missing codepage or helper program, or
Hi Liu,
1) all of them not working (see dmesg at the end)
2)
max@s0:~$ sudo btrfs scrub start /dev/sdb
ERROR: getting dev info for scrub failed: Inappropriate ioctl for device
max@s0:~$ sudo btrfs scrub start /dev/sda
ERROR: getting dev info for scrub failed: Inappropriate ioctl for device
On 06/04/2012 10:18 AM, Maxim Mikheev wrote:
Hi Liu,
1) all of them not working (see dmesg at the end)
2)
max@s0:~$ sudo btrfs scrub start /dev/sdb
ERROR: getting dev info for scrub failed: Inappropriate ioctl for device
max@s0:~$ sudo btrfs scrub start /dev/sda
ERROR: getting dev info
I tried:
max@s0:~$ sudo btrfs-restore /dev/sdb ~/restored
parent transid verify failed on 5468060241920 wanted 9096 found 7621
parent transid verify failed on 5468060241920 wanted 9096 found 7621
parent transid verify failed on 5468060241920 wanted 9096 found 7621
parent transid verify failed on
Hi Everyone,
Can I do anything else?
Max
On 06/03/2012 11:13 PM, Maxim Mikheev wrote:
I tried:
max@s0:~$ sudo btrfs-restore /dev/sdb ~/restored
parent transid verify failed on 5468060241920 wanted 9096 found 7621
parent transid verify failed on 5468060241920 wanted 9096 found 7621
parent
Repair was not helpful.
Is any other ways to get access to data?
Please help
On 05/30/2012 11:15 PM, Michael K wrote:
Let it run to completion. There is little you can do other than hope
and wait.
On May 30, 2012 9:02 PM, Maxim Mikheev mik...@gmail.com
mailto:mik...@gmail.com wrote:
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
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 Mikheevmik...@gmail.com wrote:
Thank you for your answer.
The system kernel was and now:
Linux s0 3.4.0-030400-generic
After command:
sudo /usr/local/bin/btrfs device scan
i got new lines in dmesg:
11329.598535] device fsid c9776e19-37eb-4f9c-bd6b-04e8dde97682 devid 2
transid 9096 /dev/sdb
[11329.599885] device fsid c9776e19-37eb-4f9c-bd6b-04e8dde97682 devid 3
transid 9095 /dev/sdd
[11329.600840] device
I can't help much at the moment, but the following will help sort things out:
Can you provide as much detail as possible about how things were
configured at the time of the failure? Raid levels used, kernel
versions at the time of the failure, how the disks are connected,
general description of
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.
I forgot to add.
Btrfs-tools was build from:
git clone
git://git.kernel.org/pub/scm/linux/kernel/git/mason/btrfs-progs.git
On 05/29/2012 07:24 PM, Maxim Mikheev wrote:
Thank you for your answer.
The system kernel was and now:
Linux s0 3.4.0-030400-generic #201205210521 SMP Mon May 21
On Tue, May 29, 2012 at 5:24 PM, Maxim Mikheev mik...@gmail.com 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
36 matches
Mail list logo
