linux-ext4.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [Q] e4defrag and append-only files
@ 2019-12-09 10:54 Kirill Tkhai
  2019-12-10 10:10 ` Jan Kara
  0 siblings, 1 reply; 2+ messages in thread
From: Kirill Tkhai @ 2019-12-09 10:54 UTC (permalink / raw)
  To: linux-ext4; +Cc: tytso, jack, adilger.kernel, ktkhai

Hi,

on one of production nodes I observe the situation, when many fragmented files
never become defragmented, becase of they have "a" extended attribute.
The reason is append-only file can't be open for write without O_APPEND attribute:

$lsattr a.txt
-----a--------e----- a.txt

$strace e4defrag a.txt
openat(AT_FDCWD, "a.txt", O_RDWR)       = -1 EPERM (Operation not permitted)

Simple O_APPEND passed to open() solves the situation.

The question is: can't we just do this?

Let's observe the file restrictions we may have.

"Append-only" extended attribute restriction is weaker, than RO file permissions (0444).
But RO files are being processed by e4defrag, since e4defrag runs by root, and it easily
ignores RO file permissions, while "append-only" files are always ignored by the util.
Is there a fundamental reason we must skip them?

Thanks,
Kirill

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: [Q] e4defrag and append-only files
  2019-12-09 10:54 [Q] e4defrag and append-only files Kirill Tkhai
@ 2019-12-10 10:10 ` Jan Kara
  0 siblings, 0 replies; 2+ messages in thread
From: Jan Kara @ 2019-12-10 10:10 UTC (permalink / raw)
  To: Kirill Tkhai; +Cc: linux-ext4, tytso, jack, adilger.kernel

Hi!

On Mon 09-12-19 13:54:24, Kirill Tkhai wrote:
> on one of production nodes I observe the situation, when many fragmented files
> never become defragmented, becase of they have "a" extended attribute.
> The reason is append-only file can't be open for write without O_APPEND attribute:
> 
> $lsattr a.txt
> -----a--------e----- a.txt
> 
> $strace e4defrag a.txt
> openat(AT_FDCWD, "a.txt", O_RDWR)       = -1 EPERM (Operation not permitted)
> 
> Simple O_APPEND passed to open() solves the situation.
> 
> The question is: can't we just do this?
> 
> Let's observe the file restrictions we may have.
> 
> "Append-only" extended attribute restriction is weaker, than RO file permissions (0444).
> But RO files are being processed by e4defrag, since e4defrag runs by root, and it easily
> ignores RO file permissions, while "append-only" files are always ignored by the util.
> Is there a fundamental reason we must skip them?

I don't think there's a technical reason why we cannot defragment inodes
with 'append-only' or even 'immutable' attribute. Just e4defrag would have
to remove these flags so that open can succeed (because neither append-only
nor immutable flags are overridden by CAP_DAC_OVERRIDE capability - unlike
standard unix permissions or xattrs) and then restore the flags after the
fact.

Whether we really want to do this is another question. I don't think
e4defrag should touch immutable files, for append-only files I don't have a
strong opinion...

								Honza
-- 
Jan Kara <jack@suse.com>
SUSE Labs, CR

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2019-12-10 10:10 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-12-09 10:54 [Q] e4defrag and append-only files Kirill Tkhai
2019-12-10 10:10 ` Jan Kara

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).