On Thu, 2012-08-30 at 00:48 +0200, Miklos Szeredi wrote: > Ben Hutchings writes: > > > On Wed, Aug 15, 2012 at 05:48:12PM +0200, Miklos Szeredi wrote: > >> From: Andy Whitcroft > >> > >> 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. [...] If I'm not mistaken, glibc uses it to implement pathconf(_PC_NAME_MAX), which may be used by applications in conjunction with readdir_r(). Ben. -- Ben Hutchings Quantity is no substitute for quality, but it's the only one we've got.