On 2017-04-11 05:55, Adam Borowski wrote:
On Tue, Apr 11, 2017 at 06:01:19AM +0200, Kai Krakow wrote:
Yes, I know all this. But I don't see why you still want noatime or
relatime if you use lazytime, except for super-optimizing. Lazytime
gives you POSIX conformity for a problem that the other
On Tue, Apr 11, 2017 at 06:01:19AM +0200, Kai Krakow wrote:
> Yes, I know all this. But I don't see why you still want noatime or
> relatime if you use lazytime, except for super-optimizing. Lazytime
> gives you POSIX conformity for a problem that the other options only
> tried to solve.
(Besides
Am Mon, 10 Apr 2017 15:43:57 -0400
schrieb "Austin S. Hemmelgarn" :
> On 2017-04-10 14:18, Kai Krakow wrote:
> > Am Mon, 10 Apr 2017 13:13:39 -0400
> > schrieb "Austin S. Hemmelgarn" :
> >
> >> On 2017-04-10 12:54, Kai Krakow wrote:
> [...]
>
Am Tue, 11 Apr 2017 01:45:32 +0200
schrieb "Janos Toth F." :
> >> The command-line also rejects a number of perfectly legitimate
> >> arguments that BTRFS does understand too though, so that's not much
> >> of a test.
> >
> > Which are those? I didn't encounter any...
>> The command-line also rejects a number of perfectly legitimate
>> arguments that BTRFS does understand too though, so that's not much
>> of a test.
>
> Which are those? I didn't encounter any...
I think this bug still stands unresolved (for 3+ years, probably
because most people use init-rd/fs
On Mon, Apr 10, 2017 at 03:43:57PM -0400, Austin S. Hemmelgarn wrote:
> On 2017-04-10 14:18, Kai Krakow wrote:
> * strictatime, lazytime: Both atime and mtime updates happen, but they
> actual update may not hit the disk for up to 24 hours (this will let mutt
> work correctly as long as your
On 2017-04-10 14:18, Kai Krakow wrote:
Am Mon, 10 Apr 2017 13:13:39 -0400
schrieb "Austin S. Hemmelgarn" :
On 2017-04-10 12:54, Kai Krakow wrote:
Am Mon, 10 Apr 2017 18:44:44 +0200
schrieb Kai Krakow :
Am Mon, 10 Apr 2017 08:51:38 -0400
schrieb
Am Mon, 10 Apr 2017 13:13:39 -0400
schrieb "Austin S. Hemmelgarn" :
> On 2017-04-10 12:54, Kai Krakow wrote:
> > Am Mon, 10 Apr 2017 18:44:44 +0200
> > schrieb Kai Krakow :
> >
> >> Am Mon, 10 Apr 2017 08:51:38 -0400
> >> schrieb "Austin S.
On 2017-04-10 12:54, Kai Krakow wrote:
Am Mon, 10 Apr 2017 18:44:44 +0200
schrieb Kai Krakow :
Am Mon, 10 Apr 2017 08:51:38 -0400
schrieb "Austin S. Hemmelgarn" :
On 2017-04-10 08:45, Kai Krakow wrote:
Am Mon, 10 Apr 2017 08:39:23 -0400
schrieb
Am Mon, 10 Apr 2017 18:44:44 +0200
schrieb Kai Krakow :
> Am Mon, 10 Apr 2017 08:51:38 -0400
> schrieb "Austin S. Hemmelgarn" :
>
> > On 2017-04-10 08:45, Kai Krakow wrote:
> > > Am Mon, 10 Apr 2017 08:39:23 -0400
> > > schrieb "Austin S. Hemmelgarn"
Am Mon, 10 Apr 2017 08:51:38 -0400
schrieb "Austin S. Hemmelgarn" :
> On 2017-04-10 08:45, Kai Krakow wrote:
> > Am Mon, 10 Apr 2017 08:39:23 -0400
> > schrieb "Austin S. Hemmelgarn" :
> >
> >> They've been running BTRFS
> >> with LZO compression, the
On 2017-04-10 08:45, Kai Krakow wrote:
Am Mon, 10 Apr 2017 08:39:23 -0400
schrieb "Austin S. Hemmelgarn" :
They've been running BTRFS
with LZO compression, the SSD allocator, atime disabled, and mtime
updates deferred (lazytime mount option) the whole time, so it may be
a
Am Mon, 10 Apr 2017 08:39:23 -0400
schrieb "Austin S. Hemmelgarn" :
> They've been running BTRFS
> with LZO compression, the SSD allocator, atime disabled, and mtime
> updates deferred (lazytime mount option) the whole time, so it may be
> a slightly different use case
On 2017-04-09 19:23, Hans van Kranenburg wrote:
On 04/08/2017 01:16 PM, Hans van Kranenburg wrote:
On 04/07/2017 11:25 PM, Hans van Kranenburg wrote:
Ok, I'm going to revive a year old mail thread here with interesting new
info:
[...]
Now, another surprise:
From the exact moment I did mount
On 04/08/2017 01:16 PM, Hans van Kranenburg wrote:
> On 04/07/2017 11:25 PM, Hans van Kranenburg wrote:
>> Ok, I'm going to revive a year old mail thread here with interesting new
>> info:
>>
>> [...]
>>
>> Now, another surprise:
>>
>> From the exact moment I did mount -o remount,nossd on this
On 04/08/2017 01:16 PM, Hans van Kranenburg wrote:
> On 04/07/2017 11:25 PM, Hans van Kranenburg wrote:
>> Ok, I'm going to revive a year old mail thread here with interesting new
>> info:
>>
>> [...]
>>
>> Now, another surprise:
>>
>> From the exact moment I did mount -o remount,nossd on this
On 04/07/2017 11:25 PM, Hans van Kranenburg wrote:
> Ok, I'm going to revive a year old mail thread here with interesting new
> info:
>
> [...]
>
> Now, another surprise:
>
> From the exact moment I did mount -o remount,nossd on this filesystem,
> the problem vanished.
>
>
Hans van Kranenburg posted on Fri, 07 Apr 2017 23:25:29 +0200 as
excerpted:
> So, this is why putting your /var/log, /var/lib/mailman and /var/spool
> on btrfs is a terrible idea.
>
> Because the allocator keeps walking forward every file that is created
> and then removed leaves a blank spot
[ ... ]
>>> I've got a mostly inactive btrfs filesystem inside a virtual
>>> machine somewhere that shows interesting behaviour: while no
>>> interesting disk activity is going on, btrfs keeps
>>> allocating new chunks, a GiB at a time.
[ ... ]
> Because the allocator keeps walking forward every
Ok, I'm going to revive a year old mail thread here with interesting new
info:
On 05/31/2016 03:36 AM, Qu Wenruo wrote:
>
>
> Hans van Kranenburg wrote on 2016/05/06 23:28 +0200:
>> Hi,
>>
>> I've got a mostly inactive btrfs filesystem inside a virtual machine
>> somewhere that shows
On 06/10/2016 07:07 PM, Henk Slager wrote:
On Thu, Jun 9, 2016 at 5:41 PM, Duncan <1i5t5.dun...@cox.net> wrote:
Hans van Kranenburg posted on Thu, 09 Jun 2016 01:10:46 +0200 as
excerpted:
The next question is what files these extents belong to. To find out, I
need to open up the extent items
On Thu, Jun 9, 2016 at 5:41 PM, Duncan <1i5t5.dun...@cox.net> wrote:
> Hans van Kranenburg posted on Thu, 09 Jun 2016 01:10:46 +0200 as
> excerpted:
>
>> The next question is what files these extents belong to. To find out, I
>> need to open up the extent items I get back and follow a
On Wed, Jun 8, 2016 at 5:10 PM, Hans van Kranenburg
wrote:
> Hi list,
>
>
> On 05/31/2016 03:36 AM, Qu Wenruo wrote:
>>
>>
>>
>> Hans van Kranenburg wrote on 2016/05/06 23:28 +0200:
>>>
>>> Hi,
>>>
>>> I've got a mostly inactive btrfs filesystem inside a virtual
Hans van Kranenburg posted on Thu, 09 Jun 2016 01:10:46 +0200 as
excerpted:
> The next question is what files these extents belong to. To find out, I
> need to open up the extent items I get back and follow a backreference
> to an inode object. Might do that tomorrow, fun.
>
> To be honest, I
On 06/09/2016 10:52 AM, Marc Haber wrote:
On Thu, Jun 09, 2016 at 01:10:46AM +0200, Hans van Kranenburg wrote:
So, instead of being the cause, apt-get update causing a new chunk to be
allocated might as well be the result of existing ones already filled up
with too many fragments.
The next
On Thu, Jun 09, 2016 at 01:10:46AM +0200, Hans van Kranenburg wrote:
> So, instead of being the cause, apt-get update causing a new chunk to be
> allocated might as well be the result of existing ones already filled up
> with too many fragments.
>
> The next question is what files these extents
Hi list,
On 05/31/2016 03:36 AM, Qu Wenruo wrote:
Hans van Kranenburg wrote on 2016/05/06 23:28 +0200:
Hi,
I've got a mostly inactive btrfs filesystem inside a virtual machine
somewhere that shows interesting behaviour: while no interesting disk
activity is going on, btrfs keeps allocating
Hans van Kranenburg wrote on 2016/05/06 23:28 +0200:
Hi,
I've got a mostly inactive btrfs filesystem inside a virtual machine
somewhere that shows interesting behaviour: while no interesting disk
activity is going on, btrfs keeps allocating new chunks, a GiB at a time.
A picture, telling
Hans van Kranenburg posted on Mon, 30 May 2016 23:18:20 +0200 as
excerpted:
>> Snip the dump, but curious as a user (not a dev) what command you used.
>> Presumably one of the debug commands which I'm not particularly
>> familiar with, but I wasn't aware it was even possible.
>
> It's the output
On 05/30/2016 09:55 PM, Duncan wrote:
Hans van Kranenburg posted on Mon, 30 May 2016 13:07:26 +0200 as
excerpted:
[Please don't post "upside down". Reply in context under the quoted
point, here the whole post, you're replying to. It makes further replies
in context far easier. =:^) I've
Hans van Kranenburg posted on Mon, 30 May 2016 13:07:26 +0200 as
excerpted:
[Please don't post "upside down". Reply in context under the quoted
point, here the whole post, you're replying to. It makes further replies
in context far easier. =:^) I've pasted your update at the bottom here.]
>
Hi,
since it got any followup and since I'm bold enough to bump it one more
time... :)
I really don't understand the behaviour I described. Does it ring a bell
with anyone? This system is still allocating new 1GB data chunks every 1
or 2 days without using them at all, and I have to use
32 matches
Mail list logo