Am Tue, 22 Jul 2014 03:26:39 + (UTC)
schrieb Duncan <1i5t5.dun...@cox.net>:
> Marc Joliet posted on Tue, 22 Jul 2014 01:30:22 +0200 as excerpted:
>
> > And now that the background deletion of the old snapshots is done, the file
> > system ended up at:
> >
> > # btrfs filesystem df /run/media
Marc Joliet posted on Tue, 22 Jul 2014 01:30:22 +0200 as excerpted:
> And now that the background deletion of the old snapshots is done, the file
> system ended up at:
>
> # btrfs filesystem df /run/media/marcec/MARCEC_BACKUP
> Data, single: total=219.00GiB, used=140.13GiB
> System, DUP: tota
Am Tue, 22 Jul 2014 00:30:57 +0200
schrieb Marc Joliet :
> Am Mon, 21 Jul 2014 15:22:16 +0200
> schrieb Marc Joliet :
>
> > Am Sun, 20 Jul 2014 21:44:40 +0200
> > schrieb Marc Joliet :
> >
> > [...]
> > > What I did:
> > >
> > > - delete the single largest file on the file system, a 12 GB VM im
Am Mon, 21 Jul 2014 15:22:16 +0200
schrieb Marc Joliet :
> Am Sun, 20 Jul 2014 21:44:40 +0200
> schrieb Marc Joliet :
>
> [...]
> > What I did:
> >
> > - delete the single largest file on the file system, a 12 GB VM image, along
> > with all subvolumes that contained it
> > - rsync it over aga
Am Sun, 20 Jul 2014 21:44:40 +0200
schrieb Marc Joliet :
[...]
> What I did:
>
> - delete the single largest file on the file system, a 12 GB VM image, along
> with all subvolumes that contained it
> - rsync it over again
[...]
I want to point out at this point, though, that doing those two st
On 20/07/14 14:59, Duncan wrote:
Marc Joliet posted on Sun, 20 Jul 2014 12:22:33 +0200 as excerpted:
On the other hand, the wiki [0] says that defragmentation (and
balancing) is optional, and the only reason stated for doing either is
because they "will have impact on performance".
Yes. That'
Marc Joliet posted on Sun, 20 Jul 2014 21:44:40 +0200 as excerpted:
> Am Sun, 20 Jul 2014 13:40:54 +0200 schrieb Marc Joliet :
>
>> Am Sun, 20 Jul 2014 12:22:33 +0200 schrieb Marc Joliet :
>>
>> [...]
>> > I'll try this and see, but I think I have more files >1GB than would
>> > account for this
Oh, and because I'm forgetful, here the new dmesg output. The new content
(relative to dmesg4) starts at line 2513.
--
Marc Joliet
--
"People who think they know everything really annoy those of us who know we
don't" - Bjarne Stroustrup
dmesg5.log.xz
Description: application/xz
signature.asc
Am Sun, 20 Jul 2014 13:40:54 +0200
schrieb Marc Joliet :
> Am Sun, 20 Jul 2014 12:22:33 +0200
> schrieb Marc Joliet :
>
> [...]
> > I'll try this and see, but I think I have more files >1GB than would account
> > for this error (which comes towards the end of the balance when only a few
> > chunk
Marc Joliet posted on Sun, 20 Jul 2014 12:22:33 +0200 as excerpted:
> On the other hand, the wiki [0] says that defragmentation (and
> balancing) is optional, and the only reason stated for doing either is
> because they "will have impact on performance".
Yes. That's what threw off the other guy
Am Sun, 20 Jul 2014 12:22:33 +0200
schrieb Marc Joliet :
[...]
> I'll try this and see, but I think I have more files >1GB than would account
> for this error (which comes towards the end of the balance when only a few
> chunks are left). I'll see what "find /mnt -type f -size +1G" finds :) .
No
Am Sun, 20 Jul 2014 02:39:27 + (UTC)
schrieb Duncan <1i5t5.dun...@cox.net>:
> Chris Murphy posted on Sat, 19 Jul 2014 11:38:08 -0600 as excerpted:
>
> > I'm not sure of the reason for the "BTRFS info (device sdg2): 2 enospc
> > errors during balance" but it seems informational rather than eit
Am Sat, 19 Jul 2014 18:53:03 -0600
schrieb Chris Murphy :
>
> On Jul 19, 2014, at 2:58 PM, Marc Joliet wrote:
>
> > Am Sat, 19 Jul 2014 22:10:51 +0200
> > schrieb Marc Joliet :
> >
> > [...]
> >> Another random idea: the number of errors decreased the second time I ran
> >> balance (from 4 to
Am Sat, 19 Jul 2014 19:11:00 -0600
schrieb Chris Murphy :
> I'm seeing this also in the 2nd dmesg:
>
> [ 249.893310] BTRFS error (device sdg2): free space inode generation (0) did
> not match free space cache generation (26286)
>
>
> So you could try umounting the volume. And doing a one time
Chris Murphy posted on Sat, 19 Jul 2014 11:38:08 -0600 as excerpted:
> I'm not sure of the reason for the "BTRFS info (device sdg2): 2 enospc
> errors during balance" but it seems informational rather than either a
> warning or problem. I'd treat ext4->btrfs converted file systems to be
> somethin
I'm seeing this also in the 2nd dmesg:
[ 249.893310] BTRFS error (device sdg2): free space inode generation (0) did
not match free space cache generation (26286)
So you could try umounting the volume. And doing a one time mount with the
clear_cache mount option. Give it some time to rebuild t
On Jul 19, 2014, at 2:58 PM, Marc Joliet wrote:
> Am Sat, 19 Jul 2014 22:10:51 +0200
> schrieb Marc Joliet :
>
> [...]
>> Another random idea: the number of errors decreased the second time I ran
>> balance (from 4 to 2), I could run another full balance and see if it keeps
>> decreasing.
>
>
On Sat, Jul 19, 2014 at 11:38:08AM -0600, Chris Murphy wrote:
> [96241.882138] ata2.00: exception Emask 0x1 SAct 0x7ffe0fff SErr 0x0 action
> 0x6 frozen
> [96241.882139] ata2.00: Ata error. fis:0x21
> [96241.882142] ata2.00: failed command: READ FPDMA QUEUED
> [96241.882148] ata2.00: cmd 60/08:00:
Am Sat, 19 Jul 2014 22:10:51 +0200
schrieb Marc Joliet :
[...]
> Another random idea: the number of errors decreased the second time I ran
> balance (from 4 to 2), I could run another full balance and see if it keeps
> decreasing.
Well, this time there were still 2 ENOSPC errors. But I can show
The 2nd dmesg (didn't look at the 1st), has many instances like this;
[96241.882138] ata2.00: exception Emask 0x1 SAct 0x7ffe0fff SErr 0x0 action 0x6
frozen
[96241.882139] ata2.00: Ata error. fis:0x21
[96241.882142] ata2.00: failed command: READ FPDMA QUEUED
[96241.882148] ata2.00: cmd 60/08:00:6
20 matches
Mail list logo
