Take the 2-minute tour ×
Ask Ubuntu is a question and answer site for Ubuntu users and developers. It's 100% free, no registration required.

The installation for 12.04 kept failing, and the solution was to have the installer ignore the btrfs partition that I have previously been using for /home.

Now that it's installed, I've been trying to get it to mount the btrfs partition so that I can access my 70GB of files. It won't mount, and btrfsck errors out with the following three lines:

parent transid verify failed on 31302336512 wanted 62455 found 62456
parent transid verify failed on 31302336512 wanted 62455 found 62456
parent transid verify failed on 31302336512 wanted 62455 found 62456

Can someone please tell me how to get this partition working? I've read online that I can probably recover the data using btrfs-restore, but I can't find that program anywhere.

share|improve this question
add comment

5 Answers

Mount on boot using root fs mount options:

rootflags=recovery,nospace_cache

or

rootflags=recovery,nospace_cache,clear_cache

The full list of btrfs mount options should be here https://btrfs.wiki.kernel.org/index.php/Mount_options and other things may be useful also, such as noatime,nodatacow (fixed a kernel bug for me giving me a chance to copy my files).

Add it to your grub.cfg / menu.lst, or type it in when booting.

The nospace_cache stuff will make things terribly slow. Just boot up, wait (long), shut down, and boot normally.

I had the same thing a few days ago, and the above fixed it. But also afterwards, there were some space issues... the space reported is not 100% but it can still say out of space.

==

I think you can also add the same options in your fstab, for example:

UUID=0237alksfadg-lhdfkj3624-4fdfjb-9dsfe2d-dfddaf /home btrfs defaults,recovery,nospace_cache,clear_cache,subvol=@home 0  
 2

If you were trying to recover a /home directory mounted over a partition with UUID=0237alksfadg-lhdfkj3624-4fdfjb-9dsfe2d-dfddaf.

share|improve this answer
    
Why two nospace_cache? –  Michael Kjörling Nov 6 '12 at 12:47
    
it was a typo, was supposed to be clear_cache –  Peter Nov 9 '12 at 14:02
add comment

Peter's answer solved the problem for me, although not on Ubuntu. I had a /home partition btrfs'd that got of course corrupted. The system would not boot up because it was on fstab. I entered maintenance mode, hashed out the line with that partition, and booted up normally( I had a spare ext4 partition I could use as /home).

I mounted the partition manually with the following command :

mount -t btrfs -o recovery,nospace_cache,nospace_cache /dev/sda3 /mnt/sda3 and was actually able to save my data. Although it did not take that long to mount it. So THANKS Peter.

share|improve this answer
1  
You may want to just post that as a comment on peter's answer, saying 'This worked' and then just mark that as the true answer. otherwise, Peter won't get any "true" credit (rep points) –  Thomas W. Oct 19 '12 at 17:32
add comment

Easiest way

btrfs-zero-log /dev/sda5

Your getting that issue because a transaction(write or delete) is stuck in the journal log and the disk doesnt match it.

How it works:

So when data is written 1st its written to journal then to disk (or at same time, but journal just saves metadata about the upcoming write - not sure... need more research on that part)...

Anyhow if you turn off the system in the middle of this write/delete or do something hickups the system (dismount the USB that holds your btrfs mount point), then when it returns that mount will not work it will fail (dmesg and btrfsck will show you the errors in more detail)...

Looking at dmesg you will see those same transid messages.

You will see something like this:

parent transid verify failed on 109973766144 wanted 1823 found 1821

It means that btrfs wanted transif 1826 (That was on the journal) but on the disk it saw 1821. So the disk was 2 transactions away from being in sync with journal. I personally would risk a brtfs-zero-log here just because its only 2 transactions. But to be 100% safe if this is your only data (by the way if you have critical data you should NEVER EVER have only 1 copy of it, always have a copy/backup in a safe other location - blaming the creators of btrfs wouldnt justify against the persons own lack of responsibility of not having a backup - btrfs is not backup solution, its a filesystem - nothing is a true backup solution besides having a copy of it else where - not even parity or mirrored drives, a true backup is sitting somewhere underground in the Alps while its active copy is in your office in Texas)

parent transid verify failed on 31302336512 wanted 62455 found 62456

Here the journal is wanting 62455 but the disk is one ahead at 62456, so in your case i would just clear the journal. Journal didnt update this time. Again I told you bout being safe thing, if its your only data and its mega critical (shame on you), and I would do the below operations first to be safe.

Running a btrfsck /dev/sda5 (which by the way just does a readonly check so its completely safe, its only btrfsck options that you have to worry about) will also show you those messages.

But beware if that data is critical, i would first do (As the other gents said)

mount -t btrfs -o rootflags=recovery,nospace_cache /dev/sda3 /mnt/sda3

mount -t btrfs -o rootflags=recovery,nospace_cache,clear_cache /dev/sda3 /mnt/sda3

mount -t btrfs -o recovery,nospace_cache,nospace_cache /dev/sda3 /mnt/sda3

Then cp or rsync all of your files over to safe location, then when safe do the btrfs-zero-log, if its a successful operation you just wasted alot of time backing up your system (but if its not successful, you just saved your arse)

Then if the mounts failed do a btrfs restore (dump of the system, as I understand its a resumeable operation, however it keeps asking for Y or y every now and again so watch the output)

btrfs restore /dev/sda5 /USB

Then when safe (when btrfs restore is done) do the btrfs-zero-log, if its a successful operation you just wasted alot of time backing up your system (but if its not successful, you just saved your arse)

You can run screen first

screen /bin/bash

btrfs restore /dev/sda5 /USB

SCREEN SIDE NOTE

To detach (command will still run): CONTROL-a then type ":detach" without the quotes then press ENTER

Another way to detach: Then close out of putty or your terminal and it will detach (the command / restore will still run).

To check up on it, just screen back to it:

screen -x

screen -x will attach to sessions, even if detached, and unlike -h says, it will attach even if its already attached as well)

If you have several screens, screen -x will tell you need to be more specific to attach to the session:

screen -ls

ls for list all sessions, easy to remember that.

to see the PID you can also do this:

ps aux | grep screen

Once you find out your PID, then run screen like this:

screen -x PID

That will attach to a specific session. You can have several sessions/puttys attached to the same screen (they will output the same text, you can type commands in one, and they will be mirrored on the other putty)

share|improve this answer
add comment
mount -t btrfs -o ro,nospace_cache,nospace_cache /dev/sda3 /mnt/sda3

ro = read only

This work for me

share|improve this answer
    
Did you read @The Lord of Time's comment to similar comment that was added as answer? Here it is again if you did not -"You may want to just post that as a comment on peter's answer, saying 'This worked' and then just mark that as the true answer. otherwise, Peter won't get any "true" credit (rep points) " –  geezanansa May 27 '13 at 14:41
add comment

I had the same problem. After a reboot I was no longer able to mount my btrfs partition. However none of the solutions mentioned here could solve it.

What did fix it for me was upgrading the kernel from 3.10 to 3.12. After a reboot the btrfs partition could be mounted again.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.