On Wed, Sep 18, 2019 at 12:37:42AM -0400, General Zed wrote:
> It just postpones the inevitable, but you missed the point. The point of
> shutting down dedupe is to avoid nasty bugs caused by dedupe-defrag
> interaction.
They are the same bugs you'll have to fix anyway. Dedupe isn't
particularly
Quoting Zygo Blaxell :
On Tue, Sep 17, 2019 at 06:07:24AM -0400, General Zed wrote:
Quoting Zygo Blaxell :
> I doubt that on a 50TB filesystem you need to read the whole tree...are
> you going to globally optimize 50TB at once? That will take a while.
I need to read the whole free-space tr
On Tue, Sep 17, 2019 at 06:07:24AM -0400, General Zed wrote:
>
> Quoting Zygo Blaxell :
> > I doubt that on a 50TB filesystem you need to read the whole tree...are
> > you going to globally optimize 50TB at once? That will take a while.
>
> I need to read the whole free-space tree to find a few
Quoting Zygo Blaxell :
On Mon, Sep 16, 2019 at 10:30:39PM -0400, General Zed wrote:
Quoting Zygo Blaxell :
> and I think that's impossible so I start from designs
> that make forward progress with a fixed allocation of resources.
Well, that's not useless, but it's kind of meh. Waste of time.
On Mon, Sep 16, 2019 at 10:30:39PM -0400, General Zed wrote:
> Quoting Zygo Blaxell :
> > and I think that's impossible so I start from designs
> > that make forward progress with a fixed allocation of resources.
>
> Well, that's not useless, but it's kind of meh. Waste of time. Solve the
> proble
On Mon, Sep 16, 2019 at 07:44:31PM -0600, Chris Murphy wrote:
> Reflinks are like a file based snapshot, they're a file with its own
> inode and other metadata you expect for a file, but points to the same
> extents as another file. Off hand I'm not sure other than age if
> there's any difference b
On Mon, Sep 16, 2019 at 09:03:17PM -0400, General Zed wrote:
>
> Quoting Zygo Blaxell :
> > Reflinks are the forward references--there is no other kind of forward
> > reference in btrfs (contrast with other filesystems which use one data
> > structure for single references and another for multiple
Quoting General Zed :
Quoting Zygo Blaxell :
On Sun, Sep 15, 2019 at 01:54:07PM -0400, General Zed wrote:
Quoting Zygo Blaxell :
On Fri, Sep 13, 2019 at 09:50:38PM -0400, General Zed wrote:
>
> Quoting Zygo Blaxell :
>
> > On Fri, Sep 13, 2019 at 01:05:52AM -0400, General Zed wrote:
> >
Quoting Zygo Blaxell :
On Sun, Sep 15, 2019 at 01:54:07PM -0400, General Zed wrote:
Quoting Zygo Blaxell :
> On Fri, Sep 13, 2019 at 09:50:38PM -0400, General Zed wrote:
> >
> > Quoting Zygo Blaxell :
> >
> > > On Fri, Sep 13, 2019 at 01:05:52AM -0400, General Zed wrote:
> > > >
> > > > Quo
Quoting Zygo Blaxell :
On Mon, Sep 16, 2019 at 07:42:51AM -0400, General Zed wrote:
Quoting Zygo Blaxell :
> Your defrag ideas are interesting, but you should spend a lot more
> time learning the btrfs fundamentals before continuing. Right now
> you do not understand what btrfs is capable o
On Mon, Sep 16, 2019 at 7:03 PM General Zed wrote:
>
> Ok, so a reflink contains a virtual address. Did I get that right?
>
> All extent ref items are reflinks which contain a 4 KB aligned address
> because the extents have that same alignment. Did I get that right?
>
> Virtual addresses are 8-byt
Quoting General Zed :
Quoting Zygo Blaxell :
On Sun, Sep 15, 2019 at 01:54:07PM -0400, General Zed wrote:
Quoting Zygo Blaxell :
On Fri, Sep 13, 2019 at 09:50:38PM -0400, General Zed wrote:
>
> Quoting Zygo Blaxell :
>
> > On Fri, Sep 13, 2019 at 01:05:52AM -0400, General Zed wrote:
> >
Quoting Zygo Blaxell :
On Sun, Sep 15, 2019 at 01:54:07PM -0400, General Zed wrote:
Quoting Zygo Blaxell :
> On Fri, Sep 13, 2019 at 09:50:38PM -0400, General Zed wrote:
> >
> > Quoting Zygo Blaxell :
> >
> > > On Fri, Sep 13, 2019 at 01:05:52AM -0400, General Zed wrote:
> > > >
> > > > Quo
On Mon, Sep 16, 2019 at 07:42:51AM -0400, General Zed wrote:
>
> Quoting Zygo Blaxell :
> > Your defrag ideas are interesting, but you should spend a lot more
> > time learning the btrfs fundamentals before continuing. Right now
> > you do not understand what btrfs is capable of doing easily, and
On Sun, Sep 15, 2019 at 02:05:47PM -0400, General Zed wrote:
>
> Quoting Zygo Blaxell :
> > 3% of 45TB is 1.35TB...seems a little harsh. Recall no extent can be
> > larger than 128MB, so we're talking about enough space for ten thousand
> > of defrag's worst-case output extents. A limit based on
On Sun, Sep 15, 2019 at 01:54:07PM -0400, General Zed wrote:
>
> Quoting Zygo Blaxell :
>
> > On Fri, Sep 13, 2019 at 09:50:38PM -0400, General Zed wrote:
> > >
> > > Quoting Zygo Blaxell :
> > >
> > > > On Fri, Sep 13, 2019 at 01:05:52AM -0400, General Zed wrote:
> > > > >
> > > > > Quoting Zy
Quoting Zygo Blaxell :
On Thu, Sep 12, 2019 at 05:23:21PM -0400, General Zed wrote:
Quoting Zygo Blaxell :
> On Wed, Sep 11, 2019 at 07:21:31PM -0400, webmas...@zedlx.com wrote:
> >
> > Quoting Zygo Blaxell :
[...etc...]
> > > On Wed, Sep 11, 2019 at 01:20:53PM -0400, webmas...@zedlx.com
Quoting Zygo Blaxell :
On Fri, Sep 13, 2019 at 09:28:49PM -0400, General Zed wrote:
Quoting Zygo Blaxell :
> On Fri, Sep 13, 2019 at 05:25:20AM -0400, General Zed wrote:
> >
> > Quoting General Zed :
> >
> > > Quoting Zygo Blaxell :
> > >
> > > > On Thu, Sep 12, 2019 at 08:26:04PM -0400, Ge
Quoting Zygo Blaxell :
On Fri, Sep 13, 2019 at 09:50:38PM -0400, General Zed wrote:
Quoting Zygo Blaxell :
> On Fri, Sep 13, 2019 at 01:05:52AM -0400, General Zed wrote:
> >
> > Quoting Zygo Blaxell :
> >
> > > On Thu, Sep 12, 2019 at 08:26:04PM -0400, General Zed wrote:
> > > >
> > > > Quo
On Sat, Sep 14, 2019 at 12:29:09PM -0600, Chris Murphy wrote:
> On Fri, Sep 13, 2019 at 5:04 AM Austin S. Hemmelgarn
> wrote:
> >
> > Do you have a source for this claim of a 128MB max extent size? Because
> > everything I've seen indicates the max extent size is a full data chunk
> > (so 1GB for
On Fri, Sep 13, 2019 at 5:04 AM Austin S. Hemmelgarn
wrote:
>
> Do you have a source for this claim of a 128MB max extent size? Because
> everything I've seen indicates the max extent size is a full data chunk
> (so 1GB for the common case, potentially up to about 5GB for really big
> filesystems
General Zed kirjoitti 13.9.2019 klo 22.40:
I think
everyone here can see that I am versed in programming, and very proficient
in solving the high-level issues.
No. I certainly can't. Doesn't matter how good a programmer you are.
No-one's good enough to get anywhere near my code base with the
On Sat, Sep 14, 2019 at 12:42:19AM -0400, Zygo Blaxell wrote:
> On Fri, Sep 13, 2019 at 09:50:38PM -0400, General Zed wrote:
> >
> > Quoting Zygo Blaxell :
> >
> > > On Fri, Sep 13, 2019 at 01:05:52AM -0400, General Zed wrote:
> > > >
> > > > Quoting Zygo Blaxell :
> > > >
> > > > > On Thu, Sep
On Fri, Sep 13, 2019 at 09:50:38PM -0400, General Zed wrote:
>
> Quoting Zygo Blaxell :
>
> > On Fri, Sep 13, 2019 at 01:05:52AM -0400, General Zed wrote:
> > >
> > > Quoting Zygo Blaxell :
> > >
> > > > On Thu, Sep 12, 2019 at 08:26:04PM -0400, General Zed wrote:
> > > > >
> > > > > Quoting Zy
On Fri, Sep 13, 2019 at 09:28:49PM -0400, General Zed wrote:
>
> Quoting Zygo Blaxell :
>
> > On Fri, Sep 13, 2019 at 05:25:20AM -0400, General Zed wrote:
> > >
> > > Quoting General Zed :
> > >
> > > > Quoting Zygo Blaxell :
> > > >
> > > > > On Thu, Sep 12, 2019 at 08:26:04PM -0400, General Z
On Thu, Sep 12, 2019 at 05:23:21PM -0400, General Zed wrote:
>
> Quoting Zygo Blaxell :
>
> > On Wed, Sep 11, 2019 at 07:21:31PM -0400, webmas...@zedlx.com wrote:
> > >
> > > Quoting Zygo Blaxell :
[...etc...]
> > > > On Wed, Sep 11, 2019 at 01:20:53PM -0400, webmas...@zedlx.com wrote:
> > It's
Quoting Zygo Blaxell :
On Fri, Sep 13, 2019 at 01:05:52AM -0400, General Zed wrote:
Quoting Zygo Blaxell :
> On Thu, Sep 12, 2019 at 08:26:04PM -0400, General Zed wrote:
> >
> > Quoting Zygo Blaxell :
> >
> > > Don't forget you have to write new checksum and free space tree pages.
> > > In
Quoting Zygo Blaxell :
On Fri, Sep 13, 2019 at 01:05:52AM -0400, General Zed wrote:
Quoting Zygo Blaxell :
> On Thu, Sep 12, 2019 at 08:26:04PM -0400, General Zed wrote:
> >
> > Quoting Zygo Blaxell :
> >
> > > Don't forget you have to write new checksum and free space tree pages.
> > > In
Quoting Zygo Blaxell :
On Fri, Sep 13, 2019 at 05:25:20AM -0400, General Zed wrote:
Quoting General Zed :
> Quoting Zygo Blaxell :
>
> > On Thu, Sep 12, 2019 at 08:26:04PM -0400, General Zed wrote:
> > >
> > > Quoting Zygo Blaxell :
> > >
> > > > On Thu, Sep 12, 2019 at 06:57:26PM -0400, Ge
On Fri, Sep 13, 2019 at 05:25:20AM -0400, General Zed wrote:
>
> Quoting General Zed :
>
> > Quoting Zygo Blaxell :
> >
> > > On Thu, Sep 12, 2019 at 08:26:04PM -0400, General Zed wrote:
> > > >
> > > > Quoting Zygo Blaxell :
> > > >
> > > > > On Thu, Sep 12, 2019 at 06:57:26PM -0400, General
On Fri, Sep 13, 2019 at 01:05:52AM -0400, General Zed wrote:
>
> Quoting Zygo Blaxell :
>
> > On Thu, Sep 12, 2019 at 08:26:04PM -0400, General Zed wrote:
> > >
> > > Quoting Zygo Blaxell :
> > >
> > > > Don't forget you have to write new checksum and free space tree pages.
> > > > In the worst
Quoting Zygo Blaxell :
On Fri, Sep 13, 2019 at 07:04:28AM -0400, Austin S. Hemmelgarn wrote:
On 2019-09-12 19:54, Zygo Blaxell wrote:
> On Thu, Sep 12, 2019 at 06:57:26PM -0400, General Zed wrote:
> >
> > Quoting Chris Murphy :
> >
> > > On Thu, Sep 12, 2019 at 3:34 PM General Zed
wrote:
On Fri, Sep 13, 2019 at 07:04:28AM -0400, Austin S. Hemmelgarn wrote:
> On 2019-09-12 19:54, Zygo Blaxell wrote:
> > On Thu, Sep 12, 2019 at 06:57:26PM -0400, General Zed wrote:
> > >
> > > Quoting Chris Murphy :
> > >
> > > > On Thu, Sep 12, 2019 at 3:34 PM General Zed
> > > > wrote:
> > > > >
Quoting "Austin S. Hemmelgarn" :
On 2019-09-13 12:54, General Zed wrote:
Quoting "Austin S. Hemmelgarn" :
On 2019-09-12 18:21, General Zed wrote:
Quoting "Austin S. Hemmelgarn" :
On 2019-09-12 15:18, webmas...@zedlx.com wrote:
Quoting "Austin S. Hemmelgarn" :
On 2019-09-11 17:37, w
On 2019-09-13 12:54, General Zed wrote:
Quoting "Austin S. Hemmelgarn" :
On 2019-09-12 18:21, General Zed wrote:
Quoting "Austin S. Hemmelgarn" :
On 2019-09-12 15:18, webmas...@zedlx.com wrote:
Quoting "Austin S. Hemmelgarn" :
On 2019-09-11 17:37, webmas...@zedlx.com wrote:
Quoting "
Quoting General Zed :
Quoting "Austin S. Hemmelgarn" :
On 2019-09-12 18:57, General Zed wrote:
Quoting Chris Murphy :
On Thu, Sep 12, 2019 at 3:34 PM General Zed wrote:
Quoting Chris Murphy :
On Thu, Sep 12, 2019 at 1:18 PM wrote:
It is normal and common for defrag operation to
Quoting "Austin S. Hemmelgarn" :
On 2019-09-12 18:57, General Zed wrote:
Quoting Chris Murphy :
On Thu, Sep 12, 2019 at 3:34 PM General Zed wrote:
Quoting Chris Murphy :
On Thu, Sep 12, 2019 at 1:18 PM wrote:
It is normal and common for defrag operation to use some disk space
whil
Quoting General Zed :
Quoting General Zed :
Quoting Zygo Blaxell :
On Thu, Sep 12, 2019 at 08:26:04PM -0400, General Zed wrote:
Quoting Zygo Blaxell :
On Thu, Sep 12, 2019 at 06:57:26PM -0400, General Zed wrote:
At worst, it just has to completely write-out "all metadata",
all the
Quoting "Austin S. Hemmelgarn" :
On 2019-09-12 18:21, General Zed wrote:
Quoting "Austin S. Hemmelgarn" :
On 2019-09-12 15:18, webmas...@zedlx.com wrote:
Quoting "Austin S. Hemmelgarn" :
On 2019-09-11 17:37, webmas...@zedlx.com wrote:
Quoting "Austin S. Hemmelgarn" :
On 2019-09-11
On 2019-09-12 18:21, General Zed wrote:
Quoting "Austin S. Hemmelgarn" :
On 2019-09-12 15:18, webmas...@zedlx.com wrote:
Quoting "Austin S. Hemmelgarn" :
On 2019-09-11 17:37, webmas...@zedlx.com wrote:
Quoting "Austin S. Hemmelgarn" :
On 2019-09-11 13:20, webmas...@zedlx.com wrote:
Q
On 2019-09-12 18:57, General Zed wrote:
Quoting Chris Murphy :
On Thu, Sep 12, 2019 at 3:34 PM General Zed
wrote:
Quoting Chris Murphy :
> On Thu, Sep 12, 2019 at 1:18 PM wrote:
>>
>> It is normal and common for defrag operation to use some disk space
>> while it is running. I estimate t
On 2019-09-12 19:54, Zygo Blaxell wrote:
On Thu, Sep 12, 2019 at 06:57:26PM -0400, General Zed wrote:
Quoting Chris Murphy :
On Thu, Sep 12, 2019 at 3:34 PM General Zed wrote:
Quoting Chris Murphy :
On Thu, Sep 12, 2019 at 1:18 PM wrote:
It is normal and common for defrag operation t
Quoting General Zed :
Quoting Zygo Blaxell :
On Thu, Sep 12, 2019 at 08:26:04PM -0400, General Zed wrote:
Quoting Zygo Blaxell :
On Thu, Sep 12, 2019 at 06:57:26PM -0400, General Zed wrote:
>
> At worst, it just has to completely write-out "all metadata",
all the way up
> to the super
Quoting Zygo Blaxell :
On Thu, Sep 12, 2019 at 08:26:04PM -0400, General Zed wrote:
Quoting Zygo Blaxell :
> On Thu, Sep 12, 2019 at 06:57:26PM -0400, General Zed wrote:
> >
> > Quoting Chris Murphy :
> >
> > > On Thu, Sep 12, 2019 at 3:34 PM General Zed
wrote:
> > > >
> > > >
> > > > Q
Quoting Zygo Blaxell :
On Thu, Sep 12, 2019 at 08:26:04PM -0400, General Zed wrote:
Quoting Zygo Blaxell :
> On Thu, Sep 12, 2019 at 06:57:26PM -0400, General Zed wrote:
> >
> > At worst, it just has to completely write-out "all metadata",
all the way up
> > to the super. It needs to be
Quoting Zygo Blaxell :
On Thu, Sep 12, 2019 at 08:26:04PM -0400, General Zed wrote:
Quoting Zygo Blaxell :
You mean: all metadata size is 156 GB on one of your systems. However, you
don't typically have to put ALL metadata in RAM.
You need just some parts needed for defrag operation. So, fo
Quoting Zygo Blaxell :
On Thu, Sep 12, 2019 at 08:26:04PM -0400, General Zed wrote:
Quoting Zygo Blaxell :
You mean: all metadata size is 156 GB on one of your systems. However, you
don't typically have to put ALL metadata in RAM.
You need just some parts needed for defrag operation. So, fo
Quoting Zygo Blaxell :
On Thu, Sep 12, 2019 at 08:26:04PM -0400, General Zed wrote:
Quoting Zygo Blaxell :
> Don't forget you have to write new checksum and free space tree pages.
> In the worst case, you'll need about 1GB of new metadata pages for each
> 128MB you defrag (though you get to
On Thu, Sep 12, 2019 at 08:26:04PM -0400, General Zed wrote:
>
> Quoting Zygo Blaxell :
>
> > On Thu, Sep 12, 2019 at 06:57:26PM -0400, General Zed wrote:
> > >
> > > Quoting Chris Murphy :
> > >
> > > > On Thu, Sep 12, 2019 at 3:34 PM General Zed
> > > > wrote:
> > > > >
> > > > >
> > > > >
Quoting Zygo Blaxell :
On Wed, Sep 11, 2019 at 04:01:01PM -0400, webmas...@zedlx.com wrote:
Quoting "Austin S. Hemmelgarn" :
> Not necessarily. Even ignoring the case of data deduplication (which
> needs to be considered if you care at all about enterprise usage, and is
> part of the who
Quoting Zygo Blaxell :
On Thu, Sep 12, 2019 at 06:57:26PM -0400, General Zed wrote:
Quoting Chris Murphy :
> On Thu, Sep 12, 2019 at 3:34 PM General Zed wrote:
> >
> >
> > Quoting Chris Murphy :
> >
> > > On Thu, Sep 12, 2019 at 1:18 PM wrote:
> > >>
> > >> It is normal and common for def
On Thu, Sep 12, 2019 at 06:57:26PM -0400, General Zed wrote:
>
> Quoting Chris Murphy :
>
> > On Thu, Sep 12, 2019 at 3:34 PM General Zed wrote:
> > >
> > >
> > > Quoting Chris Murphy :
> > >
> > > > On Thu, Sep 12, 2019 at 1:18 PM wrote:
> > > >>
> > > >> It is normal and common for defrag
Quoting Chris Murphy :
On Thu, Sep 12, 2019 at 3:34 PM General Zed wrote:
Quoting Chris Murphy :
> On Thu, Sep 12, 2019 at 1:18 PM wrote:
>>
>> It is normal and common for defrag operation to use some disk space
>> while it is running. I estimate that a reasonable limit would be to
>> us
Quoting "Austin S. Hemmelgarn" :
On 2019-09-12 15:18, webmas...@zedlx.com wrote:
Quoting "Austin S. Hemmelgarn" :
On 2019-09-11 17:37, webmas...@zedlx.com wrote:
Quoting "Austin S. Hemmelgarn" :
On 2019-09-11 13:20, webmas...@zedlx.com wrote:
Quoting "Austin S. Hemmelgarn" :
On 201
Quoting Zygo Blaxell :
On Wed, Sep 11, 2019 at 07:21:31PM -0400, webmas...@zedlx.com wrote:
Quoting Zygo Blaxell :
> On Wed, Sep 11, 2019 at 01:20:53PM -0400, webmas...@zedlx.com wrote:
> >
> > Quoting "Austin S. Hemmelgarn" :
> >
> > > On 2019-09-10 19:32, webmas...@zedlx.com wrote:
> > >
On Thu, Sep 12, 2019 at 3:34 PM General Zed wrote:
>
>
> Quoting Chris Murphy :
>
> > On Thu, Sep 12, 2019 at 1:18 PM wrote:
> >>
> >> It is normal and common for defrag operation to use some disk space
> >> while it is running. I estimate that a reasonable limit would be to
> >> use up to 1% of
Quoting "Austin S. Hemmelgarn" :
On 2019-09-12 15:18, webmas...@zedlx.com wrote:
Quoting "Austin S. Hemmelgarn" :
On 2019-09-11 17:37, webmas...@zedlx.com wrote:
Quoting "Austin S. Hemmelgarn" :
On 2019-09-11 13:20, webmas...@zedlx.com wrote:
Quoting "Austin S. Hemmelgarn" :
On 201
Quoting Chris Murphy :
On Thu, Sep 12, 2019 at 1:18 PM wrote:
It is normal and common for defrag operation to use some disk space
while it is running. I estimate that a reasonable limit would be to
use up to 1% of total partition size. So, if a partition size is 100
GB, the defrag can use 1
On 2019-09-12 15:18, webmas...@zedlx.com wrote:
Quoting "Austin S. Hemmelgarn" :
On 2019-09-11 17:37, webmas...@zedlx.com wrote:
Quoting "Austin S. Hemmelgarn" :
On 2019-09-11 13:20, webmas...@zedlx.com wrote:
Quoting "Austin S. Hemmelgarn" :
On 2019-09-10 19:32, webmas...@zedlx.com wr
On Thu, Sep 12, 2019 at 1:18 PM wrote:
>
> It is normal and common for defrag operation to use some disk space
> while it is running. I estimate that a reasonable limit would be to
> use up to 1% of total partition size. So, if a partition size is 100
> GB, the defrag can use 1 GB. Lets call this
Quoting "Austin S. Hemmelgarn" :
On 2019-09-11 17:37, webmas...@zedlx.com wrote:
Quoting "Austin S. Hemmelgarn" :
On 2019-09-11 13:20, webmas...@zedlx.com wrote:
Quoting "Austin S. Hemmelgarn" :
On 2019-09-10 19:32, webmas...@zedlx.com wrote:
Quoting "Austin S. Hemmelgarn" :
Given
On 2019-09-11 17:37, webmas...@zedlx.com wrote:
Quoting "Austin S. Hemmelgarn" :
On 2019-09-11 13:20, webmas...@zedlx.com wrote:
Quoting "Austin S. Hemmelgarn" :
On 2019-09-10 19:32, webmas...@zedlx.com wrote:
Quoting "Austin S. Hemmelgarn" :
Given this, defrag isn't willfully unshari
On Wed, Sep 11, 2019 at 07:21:31PM -0400, webmas...@zedlx.com wrote:
>
> Quoting Zygo Blaxell :
>
> > On Wed, Sep 11, 2019 at 01:20:53PM -0400, webmas...@zedlx.com wrote:
> > >
> > > Quoting "Austin S. Hemmelgarn" :
> > >
> > > > On 2019-09-10 19:32, webmas...@zedlx.com wrote:
> > > > >
> > > >
On 2019-09-11 11:30 p.m., Remi Gauvin wrote:
>
> This statement makes me wonder if you really belong on a Linux
> Development list.
>
>
This is why I should avoid getting into debates,, ha.. ext4 does now
have defrag.. sorry :)
signature.asc
Description: OpenPGP digital signature
On 2019-09-11 11:05 p.m., webmas...@zedlx.com wrote:
>
> Close, but essentially: yes. I'm implying that snapshots induce future
> fragmentation. The mere act of snapshoting won't create fragments
> immediately, but if there are any future writes to previously snapshoted
> files, those writes are
Quoting Remi Gauvin :
On 2019-09-11 7:21 p.m., webmas...@zedlx.com wrote:
For example, lets examine the typical home user. If he is using btrfs,
it means he probably wants snapshots of his data. And, after a few
snapshots, his data is fragmented, and the current defrag can't help
because it
On 2019-09-11 7:21 p.m., webmas...@zedlx.com wrote:
>
> For example, lets examine the typical home user. If he is using btrfs,
> it means he probably wants snapshots of his data. And, after a few
> snapshots, his data is fragmented, and the current defrag can't help
> because it does a terrible
Quoting Zygo Blaxell :
On Wed, Sep 11, 2019 at 01:20:53PM -0400, webmas...@zedlx.com wrote:
Quoting "Austin S. Hemmelgarn" :
> On 2019-09-10 19:32, webmas...@zedlx.com wrote:
> >
> > Quoting "Austin S. Hemmelgarn" :
> >
> >
> > === I CHALLENGE you and anyone else on this mailing list: ===
On Wed, Sep 11, 2019 at 04:01:01PM -0400, webmas...@zedlx.com wrote:
>
> Quoting "Austin S. Hemmelgarn" :
>
> > On 2019-09-11 13:20, webmas...@zedlx.com wrote:
> > >
> > > Quoting "Austin S. Hemmelgarn" :
> > >
> > > > On 2019-09-10 19:32, webmas...@zedlx.com wrote:
> > > > >
> > > > > Quoting
Quoting "Austin S. Hemmelgarn" :
On 2019-09-11 13:20, webmas...@zedlx.com wrote:
Quoting "Austin S. Hemmelgarn" :
On 2019-09-10 19:32, webmas...@zedlx.com wrote:
Quoting "Austin S. Hemmelgarn" :
Given this, defrag isn't willfully unsharing anything, it's just a
side-effect of how it
On Wed, Sep 11, 2019 at 01:20:53PM -0400, webmas...@zedlx.com wrote:
>
> Quoting "Austin S. Hemmelgarn" :
>
> > On 2019-09-10 19:32, webmas...@zedlx.com wrote:
> > >
> > > Quoting "Austin S. Hemmelgarn" :
> > >
>
> > >
> > > === I CHALLENGE you and anyone else on this mailing list: ===
> > >
Quoting "Austin S. Hemmelgarn" :
On 2019-09-11 13:20, webmas...@zedlx.com wrote:
Quoting "Austin S. Hemmelgarn" :
On 2019-09-10 19:32, webmas...@zedlx.com wrote:
Quoting "Austin S. Hemmelgarn" :
=== I CHALLENGE you and anyone else on this mailing list: ===
- Show me an exaple wher
On 2019-09-11 13:20, webmas...@zedlx.com wrote:
Quoting "Austin S. Hemmelgarn" :
On 2019-09-10 19:32, webmas...@zedlx.com wrote:
Quoting "Austin S. Hemmelgarn" :
=== I CHALLENGE you and anyone else on this mailing list: ===
- Show me an exaple where splitting an extent requires unshar
Quoting "Austin S. Hemmelgarn" :
On 2019-09-10 19:32, webmas...@zedlx.com wrote:
Quoting "Austin S. Hemmelgarn" :
=== I CHALLENGE you and anyone else on this mailing list: ===
- Show me an exaple where splitting an extent requires unsharing,
and this split is needed to defrag.
Mak
On Wed, Sep 11, 2019 at 08:02:40AM -0400, Austin S. Hemmelgarn wrote:
> On 2019-09-10 19:32, webmas...@zedlx.com wrote:
> >
> > Quoting "Austin S. Hemmelgarn" :
> >
> >
> > > > Defrag may break up extents. Defrag may fuse extents. But it
> > > > shouln't ever unshare extents.
> >
> > > Actually
On 2019-09-10 19:32, webmas...@zedlx.com wrote:
Quoting "Austin S. Hemmelgarn" :
Defrag may break up extents. Defrag may fuse extents. But it shouln't
ever unshare extents.
Actually, spitting or merging extents will unshare them in a large
majority of cases.
Ok, this point seems to be re
On 11.09.19 г. 1:35 ч., webmas...@zedlx.com wrote:
>
> Quoting Nikolay Borisov :
>
>
You're exactly in the pitfall of btrfs backref walk.
For btrfs, it's definitely not an easy work to do backref walk.
btrfs uses hidden backref, that means, under most case, one extent
Quoting myself webmas...@zedlx.com:
B) "sharing-defrag"
a file is share-defragmented if ALL of the following are met:
1) all extents are written on disk in neighbouring sectors in the
ascending order
2) all pairs of *adjanced* extents meet AT LEAST ONE of the
following criteria
I made a small mistake, in 2) replace the word "ONE" with "AT LEAST ONE"
B) "sharing-defrag"
a file is share-defragmented if ALL of the following are met:
1) all extents are written on disk in neighbouring sectors in the
ascending order
2) all pairs of *adjanced* extents meet AT LEAST
Quoting Qu Wenruo :
- Introduce different levels for defrag
Allow btrfs to do some calculation and space usage policy to
determine if it's a good idea to defrag some shared extents.
E.g. my extreme case, unshare the extent would make it possible to
defrag the other subvolume to free a
Quoting "Austin S. Hemmelgarn" :
Also, I don't quite understand what the poster means by "the
snapshot duplication of defrag only affects the fragmented
portions". Possibly it means approximately: if a file wasn't
modified in the current (latest) subvolume, it doesn't need to be
unshare
Quoting "Austin S. Hemmelgarn" :
Defrag may break up extents. Defrag may fuse extents. But it
shouln't ever unshare extents.
Actually, spitting or merging extents will unshare them in a large
majority of cases.
Ok, this point seems to be repeated over and over without any proof,
and
Quoting Qu Wenruo :
So here what we could do is: (From easy to hard)
- Introduce an interface to allow defrag not to touch shared extents
it shouldn't be that difficult compared to other work we are going
to do.
At least, user has their choice.
That defrag wouldn't acomplish much. You
Quoting webmas...@zedlx.com:
Quoting Qu Wenruo :
On 2019/9/10 上午9:24, webmas...@zedlx.com wrote:
Quoting Qu Wenruo :
Btrfs defrag works by creating new extents containing the old data.
So if btrfs decides to defrag, no old extents will be used.
It will all be new extents.
That's why yo
Quoting Andrei Borzenkov :
09.09.2019 20:11, webmas...@zedlx.com пишет:
...
Forgot to mention this part.
If your primary objective is to migrate your data to another device
online (mounted, without unmount any of the fs).
This is not the primary objective. The primary objective is to prod
Quoting Nikolay Borisov :
You're exactly in the pitfall of btrfs backref walk.
For btrfs, it's definitely not an easy work to do backref walk.
btrfs uses hidden backref, that means, under most case, one extent
shared by 1000 snapshots, in extent tree (shows the backref) it can
completely be
On 2019-09-09 15:26, webmas...@zedlx.com wrote:
This post is a reply to Remi Gauvin's post, but the email got lost so I
can't reply to him directly.
Remi Gauvin wrote on 2019-09-09 17:24 :
On 2019-09-09 11:29 a.m., Graham Cobb wrote:
and does anyone really care about
defrag any more?).
09.09.2019 20:11, webmas...@zedlx.com пишет:
...
>>
>> Forgot to mention this part.
>>
>> If your primary objective is to migrate your data to another device
>> online (mounted, without unmount any of the fs).
>
> This is not the primary objective. The primary objective is to produce a
> full, onl
On 10.09.19 г. 6:32 ч., webmas...@zedlx.com wrote:
>
> Quoting Qu Wenruo :
>
>> On 2019/9/10 上午9:24, webmas...@zedlx.com wrote:
>>>
>>> Quoting Qu Wenruo :
>>>
>> Btrfs defrag works by creating new extents containing the old data.
>>
>> So if btrfs decides to defrag, no old extents
On 2019-09-09 07:25, zedlr...@server53.web-hosting.com wrote:
Quoting Qu Wenruo :
1) Full online backup (or copy, whatever you want to call it)
btrfs backup [-f]
- backups a btrfs filesystem given by to a partition
(with all subvolumes).
Why not just btrfs send?
Or you want to keep the w
Quoting Qu Wenruo :
On 2019/9/10 上午9:24, webmas...@zedlx.com wrote:
Quoting Qu Wenruo :
Btrfs defrag works by creating new extents containing the old data.
So if btrfs decides to defrag, no old extents will be used.
It will all be new extents.
That's why your proposal is freaking strange
On 2019/9/10 上午9:24, webmas...@zedlx.com wrote:
>
> Quoting Qu Wenruo :
>
Btrfs defrag works by creating new extents containing the old data.
So if btrfs decides to defrag, no old extents will be used.
It will all be new extents.
That's why your proposal is freakin
Quoting Qu Wenruo :
Btrfs defrag works by creating new extents containing the old data.
So if btrfs decides to defrag, no old extents will be used.
It will all be new extents.
That's why your proposal is freaking strange here.
Ok, but: can the NEW extents still be shared?
Can only be sha
On 2019/9/10 上午8:00, Chris Murphy wrote:
> On Mon, Sep 9, 2019 at 5:44 PM Qu Wenruo wrote:
>>
>>
>>
>> On 2019/9/10 上午12:38, webmas...@zedlx.com wrote:
>>> Yes, it is true, but what you are posting so far are all 'red
>>> herring'-type arguments. It's just some irrelevant concerns, and you
>>> j
On 2019/9/10 上午8:06, webmas...@zedlx.com wrote:
>
> Quoting Qu Wenruo :
>
>> On 2019/9/10 上午12:38, webmas...@zedlx.com wrote:
>>>
>>> Quoting Qu Wenruo :
>>>
>>> 2) Sensible defrag
>>> The defrag is currently a joke.
>
> Maybe there are such cases, but I would say that a vast ma
Quoting Qu Wenruo :
On 2019/9/10 上午12:38, webmas...@zedlx.com wrote:
Quoting Qu Wenruo :
2) Sensible defrag
The defrag is currently a joke.
Maybe there are such cases, but I would say that a vast majority of
users (99,99%) in a vast majority of cases (99,99%) don't want the
defrag operat
On Mon, Sep 9, 2019 at 5:44 PM Qu Wenruo wrote:
>
>
>
> On 2019/9/10 上午12:38, webmas...@zedlx.com wrote:
> > Yes, it is true, but what you are posting so far are all 'red
> > herring'-type arguments. It's just some irrelevant concerns, and you
> > just got me explaining thinks like I would to a li
On 2019/9/10 上午12:38, webmas...@zedlx.com wrote:
>
> Quoting Qu Wenruo :
>
> 2) Sensible defrag
> The defrag is currently a joke.
>>>
>>> Maybe there are such cases, but I would say that a vast majority of
>>> users (99,99%) in a vast majority of cases (99,99%) don't want the
>>> defrag
Quoting Graham Cobb :
On 09/09/2019 13:18, Qu Wenruo wrote:
On 2019/9/9 下午7:25, zedlr...@server53.web-hosting.com wrote:
What I am complaining about is that at one point in time, after issuing
the command:
btrfs balance start -dconvert=single -mconvert=single
and before issuing the 'bt
On 2019/9/9 下午11:29, Graham Cobb wrote:
> On 09/09/2019 13:18, Qu Wenruo wrote:
>>
>>
>> On 2019/9/9 下午7:25, zedlr...@server53.web-hosting.com wrote:
>>> What I am complaining about is that at one point in time, after issuing
>>> the command:
>>> btrfs balance start -dconvert=single -mconvert
1 - 100 of 111 matches
Mail list logo
