Messages in this thread | | | From | Miklos Szeredi <> | Subject | Re: [PATCH 05/13] overlayfs: add statfs support | Date | Thu, 30 Aug 2012 00:48:28 +0200 |
| |
Ben Hutchings <ben@decadent.org.uk> writes:
> On Wed, Aug 15, 2012 at 05:48:12PM +0200, Miklos Szeredi wrote: >> From: Andy Whitcroft <apw@canonical.com> >> >> Add support for statfs to the overlayfs filesystem. As the upper layer >> is the target of all write operations assume that the space in that >> filesystem is the space in the overlayfs. There will be some inaccuracy as >> overwriting a file will copy it up and consume space we were not expecting, >> but it is better than nothing. >> >> Use the upper layer dentry and mount from the overlayfs root inode, >> passing the statfs call to that filesystem. > [...] >> +/** >> + * ovl_statfs >> + * @sb: The overlayfs super block >> + * @buf: The struct kstatfs to fill in with stats >> + * >> + * Get the filesystem statistics. As writes always target the upper layer >> + * filesystem pass the statfs to the same filesystem. >> + */ >> +static int ovl_statfs(struct dentry *dentry, struct kstatfs *buf) >> +{ >> + struct dentry *root_dentry = dentry->d_sb->s_root; >> + struct path path; >> + ovl_path_upper(root_dentry, &path); >> + >> + if (!path.dentry->d_sb->s_op->statfs) >> + return -ENOSYS; >> + return path.dentry->d_sb->s_op->statfs(path.dentry, buf); >> +} > [...] > > In case f_namelen differs between the upper and lower filesystems, you > need to return the greater of the two.
Maybe. I've never seen any app use f_namelen for anything useful.
> > Should f_type be overridden to indicate overlayfs? I'm not sure what > userland is likely to do with f_type. (For presentation to the user, > it should get the mount type name with getmntent() or libmount. And > that will just work.)
Yeah we could do that.
Thanks, Miklos
| |