On Sat, Aug 9, 2014 at 11:21 PM, Duncan <1i5t5.dun...@cox.net> wrote:
> But from rc5 on thru rc7 or 8 and
> release, unless you're one of the ones still waiting on a bug found
> earlier to be fixed, it's generally quite stable and boring.
>
> So by the time of actual .0 release, it really is
Jose Ildefonso Camargo Tolosa posted on Sat, 09 Aug 2014 13:38:46 -0500 as
excerpted:
> On Sat, Aug 9, 2014 at 12:01 PM, Duncan <1i5t5.dun...@cox.net> wrote:
>> Jose Ildefonso Camargo Tolosa posted on Sat, 09 Aug 2014 11:06:37 -0500
>> as excerpted:
>>
>>> 3.16 (still in development)
>>
>> ??
>>
>
Marc MERLIN posted on Sat, 09 Aug 2014 11:21:13 -0700 as excerpted:
> You could argue that since 3.16.0 does not have the recently found
> deadlock patch that's been plaging 15 and 16 (14 not as much for me),
> it's not usable for some (it ran about 1 day on my laptop before
> deadlocking, and may
And it is still going although the hung task message stopped long
ago (behavior similar to 3.15), it hasn't finished mounting, mount is
still taking 100% CPU, *and* I can't see any disk activity at all.
Last hung task message:
[21131.749759] INFO: task btrfs-transacti:7353 blocked for more tha
3.14.16 test is on its way, it already started with this:
[19732.769100] BTRFS: device fsid 7356e329-62ba-49fb-83cc-f6b91ac3b581
devid 1 transid 111580 /dev/sdb1
[19732.769429] BTRFS info (device sdb1): enabling auto recovery
[19732.769433] BTRFS info (device sdb1): force clearing of disk cache
[2
On 08/09/2014 04:22 PM, Filipe Manana wrote:
> Under rare circumstances we can end up leaving 2 versions of a checksum
> for the same file extent range.
>
> The reason for this is that after calling btrfs_next_leaf we process
> slot 0 of the leaf it returns, instead of processing the slot set in
On Sat, Aug 09, 2014 at 09:22:27PM +0100, Filipe Manana wrote:
(100 lines of detailled explanations snipped)
> - slot = 0;
> + slot = path->slots[0];
And this is why, trying to rank kernel contributions by number of
lines or characters is a very poor guide
I'm getting on a plane right now to kiss you, be prepared. Thanks,
Josef
Filipe Manana wrote:
Under rare circumstances we can end up leaving 2 versions of a checksum
for the same file extent range.
The reason for this is that after calling btrfs_next_leaf we process
slot 0 of the leaf it ret
Under rare circumstances we can end up leaving 2 versions of a checksum
for the same file extent range.
The reason for this is that after calling btrfs_next_leaf we process
slot 0 of the leaf it returns, instead of processing the slot set in
path->slots[0]. Most of the time (by far) path->slots[0]
On Sat, Aug 9, 2014 at 12:01 PM, Duncan <1i5t5.dun...@cox.net> wrote:
> Jose Ildefonso Camargo Tolosa posted on Sat, 09 Aug 2014 11:06:37 -0500 as
> excerpted:
>
>> 3.16 (still in development)
>
> ??
>
> 3.16 has been out for nearly a week now and we're nearing half-way thru
> the 3.17 commit-windo
On Sat, Aug 09, 2014 at 05:01:24PM +, Duncan wrote:
> Jose Ildefonso Camargo Tolosa posted on Sat, 09 Aug 2014 11:06:37 -0500 as
> excerpted:
>
> > 3.16 (still in development)
>
> ??
>
> 3.16 has been out for nearly a week now and we're nearing half-way thru
> the 3.17 commit-window. Based
Jose Ildefonso Camargo Tolosa posted on Sat, 09 Aug 2014 11:06:37 -0500 as
excerpted:
> 3.16 (still in development)
??
3.16 has been out for nearly a week now and we're nearing half-way thru
the 3.17 commit-window. Based on the kernel git I have here, Linus'
commit officially changing the mak
Re-sending to list.
On Sat, Aug 9, 2014 at 9:58 AM, Jose Ildefonso Camargo Tolosa
wrote:
> On Sat, Aug 9, 2014 at 9:32 AM, Andy Smith wrote:
>> Hello,
>>
>> On Sat, Aug 09, 2014 at 01:38:34PM +1000, Russell Coker wrote:
>>> On Fri, 8 Aug 2014 16:35:29 Jose Ildefonso Camargo Tolosa wrote:
>>> > T
On Sat, Aug 9, 2014 at 9:32 AM, Andy Smith wrote:
> Hello,
>
> On Sat, Aug 09, 2014 at 01:38:34PM +1000, Russell Coker wrote:
>> On Fri, 8 Aug 2014 16:35:29 Jose Ildefonso Camargo Tolosa wrote:
>> > Then, after reading here and there, decided to try to use a newer
>> > kernel, tried 3.15.8. Well,
Hello,
On Sat, Aug 09, 2014 at 01:38:34PM +1000, Russell Coker wrote:
> On Fri, 8 Aug 2014 16:35:29 Jose Ildefonso Camargo Tolosa wrote:
> > Then, after reading here and there, decided to try to use a newer
> > kernel, tried 3.15.8. Well, it is still mounting after ~16 hours, and
> > I got messag
On 8/9/14, 6:51 AM, Andrey Utkin wrote:
> The issue was introduced in a79b7d4b3e8118f265dcb4bdf9a572c392f02708,
> adding allocation of extent_workers, so this stray check is surely not
> meant to be a check of something else.
>
> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=82021
> Report
The issue was introduced in a79b7d4b3e8118f265dcb4bdf9a572c392f02708,
adding allocation of extent_workers, so this stray check is surely not
meant to be a check of something else.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=82021
Reported-by: Maks Naumov
Signed-off-by: Andrey Utkin
---
Here is an simplified excerpt of my backup bash script:
CURRENT_TIME=$(date +"%Y-%m-%d_%H:%M-%S")
# LAST_TIME variable contains the timestamp of the last backup in the same
format as $CURRENT_TIME
btrfs subvolume snapshot -r /mnt/root/@home /mnt/root/@home-
backup-$CURRENT_TIME
sync
# Define sp
18 matches
Mail list logo
