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 fi
---
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 printf
Chris Murphy 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 line "un
On 09/02/2013 12:55 PM, Harald Hoyer wrote:
> On 06/18/2013 05:29 PM, har...@redhat.com wrote:
>> From: Harald Hoyer
>>
>> 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/fo
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 wrote:
> > > On Fri, Sep 13, 2013 at 8:15 AM, Russell King
> > > wrote:
> > >> On Fri, Sep 13, 2013 at 07:53:21AM -0400, Jo
On Sep 14, 2013, at 11:05 AM, Mathew Kamkar 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 this list: send
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 filesystem
