Re: [RFC PATCH V4] ovl: fix rmdir problem on origin dir

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

 



On 2017/6/28 18:24, Amir Goldstein wrote:
> On Wed, Jun 28, 2017 at 12:15 PM, zhangyi (F) <yi.zhang@xxxxxxxxxx> wrote:
>> BTW, I have a question, many features of overlayfs rely
>> on xattr/whiteouts of underlaying dir now, but xattr may
>> have some inconformity before we mount overlayfs or
>> "umount --> modify underlaying dir --> mount again"
>> (.e.g this whiteout case), so we cannot guarantee it's
>> behavior meet users expectations. Do you think we can make
>> a tools like e2fsck of Extfs in the future, let users to
>> check underlaying dir before mount? I think it can do the
>> following things:
>>
>> (1) Check invalid whiteouts and auto fix or ask user.
>> (2) Check redirect/impure/opaque xattr.
> (3) Check origin of merge dirs and auto fix them or ask user
> 
> 
> I think having to create fsck.overlay is inevitable.
> With the new inode index feature, a lot more can and needs to
> be checked. Specifically, inodes index checks that lower root dir
> matches origin stored in upper root dir and fails to mount overlay.
> 
> In order to allow mounting an indexed overlay after copying
> layers (to new lower inodes), a tool must be provided to perform
> 'checkpoint/restart' functionality, which converts 'origin' xattr
> (by fh) to 'redirect' xattr (by path) and vice versa.
> 
> As part of my TODO for overlayfs snapshots, I must deal with
> the 'checkpoint' part, so I do plan to start a poor mans
> implementation of an overlayfs-utils tool, but I have no plans to
> maintain a proper distribution packaged tool at community standard.
> 
> If you wish to start writing a proper tool, which performs the checks
> that you listed, that would be most welcome. You are welcome to
> contribute the code to the project I prepared for that purpose:
> https://github.com/amir73il/overlayfs
> 

I am glad to do some contribution, but I am not sure I have enough
time or not. Anyway, I can have a try in my spare time, thanks.

>> @@ -522,6 +525,7 @@ int ovl_check_empty_dir(struct dentry *dentry, struct list_head *list)
>>  {
>>         int err;
>>         struct ovl_cache_entry *p;
>> +       struct ovl_cache_entry *n;
> 
> nit: I would do *p, *n;
> It's a matter of taste I suppose, because Miklos chose otherwise in
> ovl_cache_free()
> 

Yes, it's more cleaner, thanks for your suggestion.

Thanks,
ZhangYi.


--
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



[Index of Archives]     [Linux Filesystems Devel]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux