Re: [Q] e4defrag and append-only files

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxx>
SUSE Labs, CR



[Index of Archives]     [Reiser Filesystem Development]     [Ceph FS]     [Kernel Newbies]     [Security]     [Netfilter]     [Bugtraq]     [Linux FS]     [Yosemite National Park]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Device Mapper]     [Linux Media]

  Powered by Linux