Quoting General Zed <general-...@zedlx.com>:
Quoting Zygo Blaxell <ce3g8...@umail.furryterror.org>:
On Sun, Sep 15, 2019 at 01:54:07PM -0400, General Zed wrote:
Quoting Zygo Blaxell <ce3g8...@umail.furryterror.org>:
On Fri, Sep 13, 2019 at 09:50:38PM -0400, General Zed wrote:
>
> Quoting Zygo Blaxell <ce3g8...@umail.furryterror.org>:
>
> > On Fri, Sep 13, 2019 at 01:05:52AM -0400, General Zed wrote:
> > >
> > > Quoting Zygo Blaxell <ce3g8...@umail.furryterror.org>:
> > >
> > > > On Thu, Sep 12, 2019 at 08:26:04PM -0400, General Zed wrote:
> > > > >
> > > > > Quoting Zygo Blaxell <ce3g8...@umail.furryterror.org>:
I have a few questions for you.
1. Does the btrfs driver already keep a cache off all the mentioned
trees (entent tree, subvol tree, free space tree, csum tree) in RAM?
I guess the answer is YES. This makes defrag easier to implement.
2. Is the size of those caches dynamically configurable?
I guess the answer is YES. This makes defrag easier to implement.
3. Can the cache size of csum tree be increased to approx. 128 MB. ,
for example?
I guess the answer is YES. This makes defrag easier to implement.
4. This is a part of format of subvol tree that I don't understand. You said:
"A file consists of an inode item followed by extent ref items (aka
reflinks) in a subvol tree keyed by (inode, offset) pairs. Subvol tree
pages can be shared with other subvol trees to make snapshots."
Those "extent ref items" must also be forming a tree. But how are
nodes of this tree addressed? The inode&offset is the key, but how
do you get an address of a child node?
Do nodes in the subvol tree equal the metadata extents? Or is this
tree special in that regard? Because, it seems a bit ridiculous to
have (for example) a 16 KB metadata extent for each directory or a
16 K metadata extent in the subvol tree for a file that is only a
few bytes in length.
Oh, I think I get the answer to 4.
There can be multiple directory items per metadata extent and multiple
inode items per metadata extent. Bu t they all have the same parent.
So a file will just have an inode item, but this inode item will not
occupy the entire metadata extent. Also, there could be some smart
optimizations there so that the inode reflinks-to-file-extents are
pack together with inode header.
That means there are no stale entries in any metadata extents. There
are only stale metadata extents i.e. unused metadata extents. But,
they would be enumerated in the free extents tree, right? Did I get
that right?
