[LSF/MM ATTEND] Attendance request

[LSF/MM ATTEND] Attendance request

[Liu Bo]

Hi,

I'd like to attend the LSF/MM conference this year.

I think I can contribute to a few areas that are being discussed this year:
  - how to provide better information for the filesystem to optimize allocation.
  - power/failure tests
  - performance aspects, etc.

Besides that, I'd like to talk about the following,
  - combining overlayfs with btrfs to properly fix overlayfs copy-up slowness.
  - fragmentation control in Copy-On-Write filesystems. (setting a reasonable
    large allocation unit and performing RMW, etc?)
    Since xfs is also going to have reflink, so xfs is also regarded as COW
    FS, having some generic ideas for this topic would help a lot.
  - mount individual subvolumes (in btrfs) with different selinux label, this
    will be useful in container senarios when btrfs being their storage driver.

(I've finished the patch for the above selinux label support, but it can ends up
with inode leak if it's not used in the container way, which is assuming the
top subvolume is always being the last one to unmout.)

thanks,

-liubo

Re: [LSF/MM ATTEND] Attendance request

[David Sterba]

On Sun, Feb 28, 2016 at 03:16:15PM -0800, Liu Bo wrote:
> Hi,
> 
> I'd like to attend the LSF/MM conference this year.
> 
> I think I can contribute to a few areas that are being discussed this year:
>   - how to provide better information for the filesystem to optimize allocation.
>   - power/failure tests
>   - performance aspects, etc.
> 
> Besides that, I'd like to talk about the following,
>   - combining overlayfs with btrfs to properly fix overlayfs copy-up slowness.
>   - fragmentation control in Copy-On-Write filesystems. (setting a reasonable
>     large allocation unit and performing RMW, etc?)
>     Since xfs is also going to have reflink, so xfs is also regarded as COW
>     FS, having some generic ideas for this topic would help a lot.
>   - mount individual subvolumes (in btrfs) with different selinux label, this
>     will be useful in container senarios when btrfs being their storage driver.
> 
> (I've finished the patch for the above selinux label support, but it can ends up
> with inode leak if it's not used in the container way, which is assuming the
> top subvolume is always being the last one to unmout.)

Do you have the patchset so I can have a look? I've claimed the
per-subvolume mount properties in the past and have it almost working.
Supporting selinux labels seems to have some overlap, so I'm curious how
much code conflicts are there.

Re: [LSF/MM ATTEND] Attendance request

[Liu Bo]

On Fri, Mar 04, 2016 at 03:30:58PM +0100, David Sterba wrote:
> On Sun, Feb 28, 2016 at 03:16:15PM -0800, Liu Bo wrote:
> > Hi,
> > 
> > I'd like to attend the LSF/MM conference this year.
> > 
> > I think I can contribute to a few areas that are being discussed this year:
> >   - how to provide better information for the filesystem to optimize allocation.
> >   - power/failure tests
> >   - performance aspects, etc.
> > 
> > Besides that, I'd like to talk about the following,
> >   - combining overlayfs with btrfs to properly fix overlayfs copy-up slowness.
> >   - fragmentation control in Copy-On-Write filesystems. (setting a reasonable
> >     large allocation unit and performing RMW, etc?)
> >     Since xfs is also going to have reflink, so xfs is also regarded as COW
> >     FS, having some generic ideas for this topic would help a lot.
> >   - mount individual subvolumes (in btrfs) with different selinux label, this
> >     will be useful in container senarios when btrfs being their storage driver.
> > 
> > (I've finished the patch for the above selinux label support, but it can ends up
> > with inode leak if it's not used in the container way, which is assuming the
> > top subvolume is always being the last one to unmout.)
> 
> Do you have the patchset so I can have a look? I've claimed the
> per-subvolume mount properties in the past and have it almost working.
> Supporting selinux labels seems to have some overlap, so I'm curious how
> much code conflicts are there.

There might be some conflicts since I'm using pseudo superblock for each
subvolume in that case in order to support selinux label.

Here is the patch,

https://github.com/liubogithub/btrfs-work/commit/00765203698d7e8a795d72488aefc9e19ab70b6e

Thanks,

-liubo

Re: [LSF/MM ATTEND] Attendance request

[Liu Bo]

On Fri, Mar 04, 2016 at 08:53:15AM -0800, Liu Bo wrote:
> On Fri, Mar 04, 2016 at 03:30:58PM +0100, David Sterba wrote:
> > On Sun, Feb 28, 2016 at 03:16:15PM -0800, Liu Bo wrote:
> > > Hi,
> > > 
> > > I'd like to attend the LSF/MM conference this year.
> > > 
> > > I think I can contribute to a few areas that are being discussed this year:
> > >   - how to provide better information for the filesystem to optimize allocation.
> > >   - power/failure tests
> > >   - performance aspects, etc.
> > > 
> > > Besides that, I'd like to talk about the following,
> > >   - combining overlayfs with btrfs to properly fix overlayfs copy-up slowness.
> > >   - fragmentation control in Copy-On-Write filesystems. (setting a reasonable
> > >     large allocation unit and performing RMW, etc?)
> > >     Since xfs is also going to have reflink, so xfs is also regarded as COW
> > >     FS, having some generic ideas for this topic would help a lot.
> > >   - mount individual subvolumes (in btrfs) with different selinux label, this
> > >     will be useful in container senarios when btrfs being their storage driver.
> > > 
> > > (I've finished the patch for the above selinux label support, but it can ends up
> > > with inode leak if it's not used in the container way, which is assuming the
> > > top subvolume is always being the last one to unmout.)
> > 
> > Do you have the patchset so I can have a look? I've claimed the
> > per-subvolume mount properties in the past and have it almost working.
> > Supporting selinux labels seems to have some overlap, so I'm curious how
> > much code conflicts are there.
> 
> There might be some conflicts since I'm using pseudo superblock for each
> subvolume in that case in order to support selinux label.

I also changed docker's btrfs graphdriver code to mount a
subvolume/snapshot like what devicemapper does so that it can have
different selinux label for each container.

To test it, we have to use "mount -osubvolid=AAA,nosharecache=AAA /disk /mnt"

Thanks,

-liubo

> 
> Here is the patch,
> 
> https://github.com/liubogithub/btrfs-work/commit/00765203698d7e8a795d72488aefc9e19ab70b6e
> 
> Thanks,
> 
> -liubo

Re: [LSF/MM ATTEND] Attendance request

[David Sterba]

On Fri, Mar 04, 2016 at 08:59:06AM -0800, Liu Bo wrote:
> On Fri, Mar 04, 2016 at 08:53:15AM -0800, Liu Bo wrote:
> > On Fri, Mar 04, 2016 at 03:30:58PM +0100, David Sterba wrote:
> > > On Sun, Feb 28, 2016 at 03:16:15PM -0800, Liu Bo wrote:
> > > > Hi,
> > > > 
> > > > I'd like to attend the LSF/MM conference this year.
> > > > 
> > > > I think I can contribute to a few areas that are being discussed this year:
> > > >   - how to provide better information for the filesystem to optimize allocation.
> > > >   - power/failure tests
> > > >   - performance aspects, etc.
> > > > 
> > > > Besides that, I'd like to talk about the following,
> > > >   - combining overlayfs with btrfs to properly fix overlayfs copy-up slowness.
> > > >   - fragmentation control in Copy-On-Write filesystems. (setting a reasonable
> > > >     large allocation unit and performing RMW, etc?)
> > > >     Since xfs is also going to have reflink, so xfs is also regarded as COW
> > > >     FS, having some generic ideas for this topic would help a lot.
> > > >   - mount individual subvolumes (in btrfs) with different selinux label, this
> > > >     will be useful in container senarios when btrfs being their storage driver.
> > > > 
> > > > (I've finished the patch for the above selinux label support, but it can ends up
> > > > with inode leak if it's not used in the container way, which is assuming the
> > > > top subvolume is always being the last one to unmout.)
> > > 
> > > Do you have the patchset so I can have a look? I've claimed the
> > > per-subvolume mount properties in the past and have it almost working.
> > > Supporting selinux labels seems to have some overlap, so I'm curious how
> > > much code conflicts are there.
> > 
> > There might be some conflicts since I'm using pseudo superblock for each
> > subvolume in that case in order to support selinux label.
> 
> I also changed docker's btrfs graphdriver code to mount a
> subvolume/snapshot like what devicemapper does so that it can have
> different selinux label for each container.
> 
> To test it, we have to use "mount -osubvolid=AAA,nosharecache=AAA /disk /mnt"

Thanks. Code-wise there are no conflicts but my implementation does not
expect existence of the extra superblocks so it would not work together.

Re: [LSF/MM ATTEND] Attendance request

[Liu Bo]

On Fri, Mar 04, 2016 at 06:25:14PM +0100, David Sterba wrote:
> On Fri, Mar 04, 2016 at 08:59:06AM -0800, Liu Bo wrote:
> > On Fri, Mar 04, 2016 at 08:53:15AM -0800, Liu Bo wrote:
> > > On Fri, Mar 04, 2016 at 03:30:58PM +0100, David Sterba wrote:
> > > > On Sun, Feb 28, 2016 at 03:16:15PM -0800, Liu Bo wrote:
> > > > > Hi,
> > > > > 
> > > > > I'd like to attend the LSF/MM conference this year.
> > > > > 
> > > > > I think I can contribute to a few areas that are being discussed this year:
> > > > >   - how to provide better information for the filesystem to optimize allocation.
> > > > >   - power/failure tests
> > > > >   - performance aspects, etc.
> > > > > 
> > > > > Besides that, I'd like to talk about the following,
> > > > >   - combining overlayfs with btrfs to properly fix overlayfs copy-up slowness.
> > > > >   - fragmentation control in Copy-On-Write filesystems. (setting a reasonable
> > > > >     large allocation unit and performing RMW, etc?)
> > > > >     Since xfs is also going to have reflink, so xfs is also regarded as COW
> > > > >     FS, having some generic ideas for this topic would help a lot.
> > > > >   - mount individual subvolumes (in btrfs) with different selinux label, this
> > > > >     will be useful in container senarios when btrfs being their storage driver.
> > > > > 
> > > > > (I've finished the patch for the above selinux label support, but it can ends up
> > > > > with inode leak if it's not used in the container way, which is assuming the
> > > > > top subvolume is always being the last one to unmout.)
> > > > 
> > > > Do you have the patchset so I can have a look? I've claimed the
> > > > per-subvolume mount properties in the past and have it almost working.
> > > > Supporting selinux labels seems to have some overlap, so I'm curious how
> > > > much code conflicts are there.
> > > 
> > > There might be some conflicts since I'm using pseudo superblock for each
> > > subvolume in that case in order to support selinux label.
> > 
> > I also changed docker's btrfs graphdriver code to mount a
> > subvolume/snapshot like what devicemapper does so that it can have
> > different selinux label for each container.
> > 
> > To test it, we have to use "mount -osubvolid=AAA,nosharecache=AAA /disk /mnt"
> 
> Thanks. Code-wise there are no conflicts but my implementation does not
> expect existence of the extra superblocks so it would not work together.

Hmm..I made it only affecting inode, but as we already use different inode
namespace for each subvolume and in fact we're using pseudo superblock
in order to manage multiple disk, I think it'd be fine to use any
per-subvolume properties.

Thanks,

-liubo

[LSF/MM ATTEND] attendance request

[Andreas Dilger]

[-- Attachment #1: Type: text/plain, Size: 640 bytes --]

I'd like to attend LSF/MM for the filesystem track.

There are a few areas that are being discussed this year where I can contribute:
- multi-threaded directory operations (Al/Dave)
    - we have a patch to do parallel lookup/create/unlink for ext4 with proper
      internal ext4 tree/name locking, but need the VFS locking to allow it
- online fsck - we implemented this for Lustre using chunkfs-like backpointers
- improved filesystem/block device information/interfaces
  - IO labeling to "de-anonymize" blocks at the storage layer
  - better information for the filesystem to optimize allocation

Cheers, Andreas






[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 833 bytes --]