On 2/23/20 11:30 PM, Amir Goldstein wrote:
On Sun, Feb 23, 2020 at 6:02 PM Allison Collins
<allison.henderson@xxxxxxxxxx> wrote:
On 2/23/20 12:55 AM, Amir Goldstein wrote:
On Sun, Feb 23, 2020 at 4:06 AM Allison Collins
<allison.henderson@xxxxxxxxxx> wrote:
Hi all,
This set is a subset of a larger series for delayed attributes. Which is
a subset of an even larger series, parent pointers. Delayed attributes
allow attribute operations (set and remove) to be logged and committed
in the same way that other delayed operations do. This allows more
complex operations (like parent pointers) to be broken up into multiple
smaller transactions. To do this, the existing attr operations must be
modified to operate as either a delayed operation or a inline operation
since older filesystems will not be able to use the new log entries.
High level question, before I dive into the series:
Which other "delayed operations" already exist?
I think delayed operations were added by Darrick to handle the growth of
translation size due to reflink. Right? So I assume the existing delayed
operations deal with block accounting.
Gosh, quite a few I think, but I'm not solid on what they all do. If we
take a peek at XFS_LI_TYPE_DESC, theres an identifier for each type, to
give you an idea. A lot of them do look like they are part of reflink
operations though.
When speaking of parent pointers, without having looked into the details yet,
it seem the delayed operations we would want to log are operations that deal
with namespace changes, i.e.: link,unlink,rename.
The information needed to be logged for these ops is minimal.
Why do we need a general infrastructure for delayed attr operations?
Thanks,
Amir.
Great question, this one goes back a ways. I believe the train of logic
we had is that because parent pointers also include the filename of the
parent, its possible we can end up with really big attributes. Which
may run into a lot of block map/unmap activity for name space changes.
We didnt want to end up with overly large transactions in the log, so we
wanted to break them up by returning -EAGAIN where ever the transactions
used to be rolled. I'm pretty sure that covers a quick high level
history of where we are now? Did that answer your question?
Partly.
My question was like this:
It seems that your work is about implementing:
[intent to set xattr <new parent inode,gen,offset> <new name>]
[intent to remove xattr <old parent inode,gen,offset> <old name>]
While at a high level what the user really *intents* to do is:
[intent to link <inode> to <new parent inode>;<new name>]
[intent to unlink <inode> from <old parent inode>;<old name>]
I guess the log item sizes of the two variants is quite similar, so it
doesn't make much of a difference and deferred xattr ops are more
generic and may be used for other things in the future.
Another thing is that the transaction space required from directory
entry changes is (probably) already taken into account correctly
in the code, so there is no need to worry about deferred namespace
operations from that aspect, but from a pure design perspective,
if namespace operations become complex, *they* are the ones
that should be made into deferred operations.
Or maybe I am not reading the situations correctly at all...
Ok, I think I understand what you're trying to say. Would it help to
explain then that setting or removing an attr becomes part of the
namespace operations later? When we get up into the parent pointer set,
a lot of those patches add an attribute set or remove every time we
link, unlink, rename etc. Did that help answer your question?
Allison
Thanks,
Amir.
