I'm using Btrfs v0.20-rc1-253-g7854c8b on kernel 3.10.10-1-ARCH. I've
been using this btrfs filesystem on an SSD for a little under a year
with no problems until now. I noticed it was getting a bit full (~79%)
and tried to do some cleanup by removing old snapshots. Immediately
after, the
On Sep 14, 2013, at 11:05 AM, Mathew Kamkar mat...@gmail.com wrote:
Luckily, mounting the filesystem read-only,
I was able to copy all my data and rebuild the filesystem.
Did you create a new btrfs volume? Or were you somehow able to repair the old
one?
Chris Murphy
--
To unsubscribe from
On Fri, Sep 13, 2013 at 04:58:36PM +0100, Russell King wrote:
On Fri, Sep 13, 2013 at 11:38:15AM -0400, Josh Boyer wrote:
On Fri, Sep 13, 2013 at 11:06 AM, Josh Boyer jwbo...@gmail.com wrote:
On Fri, Sep 13, 2013 at 8:15 AM, Russell King r...@arm.linux.org.uk
wrote:
On Fri, Sep 13,
On 09/02/2013 12:55 PM, Harald Hoyer wrote:
On 06/18/2013 05:29 PM, har...@redhat.com wrote:
From: Harald Hoyer har...@redhat.com
Given the following /etc/fstab entries:
/dev/sda3 /mnt/foo btrfs subvol=foo,ro 0
/dev/sda3 /mnt/bar btrfs subvol=bar,rw 0
you can't issue:
$ mount /mnt/foo
Chris Murphy lists at colorremedies.com writes:
Did you create a new btrfs volume? Or were you somehow able to repair the
old one?
No I wasn't able to repair the old one. I used rsync to copy the data,
created a new volume, then rsync copied it back.
--
To unsubscribe from this list: send the
---
btrfs fi show
Label: none uuid: a2446ecf-68c5-4815-8b63-099d10fc373c mounted: /btrfs
Group profile: metadata: single metadata: DUP data: single
I didn't notice that before, this does not bring much information
without the numbers as 'fi df' does. Please drop the
Glad that you noticed. as I did when error strings
were given the error-code at the kernel patch
183860f btrfs: device delete to get errors from the kernel
which didn't alter the original error strings.
Now, The new error string proposed here is wrong as shown below..
-
# btrfs
