On Wed, Aug 16, 2017 at 12:19 PM, Miklos Szeredi <miklos@xxxxxxxxxx> wrote:
> On Tue, Aug 15, 2017 at 6:16 PM, Amir Goldstein <amir73il@xxxxxxxxx> wrote:
>> On Tue, Aug 15, 2017 at 5:56 PM, Vivek Goyal <vgoyal@xxxxxxxxxx> wrote:
>
>>> IIUC, so now "chattr -p <id>" will fail on overlayfs (assume file has not
>>> been copied up yet).
>>>
>>
>> Yap.
>>
>>> IOW, on overlayfs, will it be responsibility of user space to make
>>> sure file has been copied up, for chattr operation to succeed? Does that
>>> mean we need to modify chattr to open file for WRITE instead of READ.
>>>
>>
>> I guess that would make sense.
>> I only wonder what was the reason for chattr to open RDONLY in
>> the first place (cc Ted)??
>
> What about copy up of flags? Should we?
IMO we should start with copying KSTAT_ATTR_FS_IOC_FLAGS,
which can already be available in kstat.
Other "standard" FS_IOC_FLAGS can be copied up when statx
gets support for those flags.
FYI, chattr [+/-]<flags> does:
- fgetflags(&flags): {open OPEN_FLAGS; ioctl EXT2_IOC_GETFLAGS}
- change flags
- fsetflags(&flags): {open OPEN_FLAGS; ioctl EXT2_IOC_SETFLAGS}
OPEN_FLAGS is defined independently in lib/e2p/f{get,set}flags.c as
(O_RDONLY|O_NONBLOCK|O_LARGEFILE), so technically all it
takes is to change the defined in lib/e2p/fsetflags.c to O_RDWR
and then chattr [+/-]<flags> can be used for preemptive "copy up flags"
by userspace (*) to work around issues which require flags copy up.
(*) At least with ext4 chattr would only "copy up" the
EXT4_FL_USER_MODIFIABLE flags, which is probably for the best.
Amir.
--
To unsubscribe from this list: send the line "unsubscribe linux-unionfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
