Message-Id: <201503231454.57319.wrosner@tirnet.de>
Date:	Mon, 23 Mar 2015 14:54:57 +0100
From:	Wolfgang Rosner <wrosner@...net.de>
To:	"Zimmermann, Alexander" <Alexander.Zimmermann@...app.com>
Cc:	"netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: One way TCP bottleneck over 6 x Gbit tecl aggregated link // Kernel issue

Am Montag, 23. März 2015 10:25:33 schrieben Sie:
> Hi Wolfgang,
>
> > Am 23.03.2015 um 10:05 schrieb Wolfgang Rosner <wrosner@...net.de>:
> >
> > Am Montag, 23. März 2015 03:33:17 schrieb Eric Dumazet:
> >> On Mon, 2015-03-23 at 01:57 +0100, Wolfgang Rosner wrote:
> >>> Are you ready to assist me on this track?
> >>
> >> First check if the problem is already solved, using this git tree ?
> >>
> >> http://git.kernel.org/cgit/linux/kernel/git/davem/net.git
> >
> > Is it OK to use this 3.19 tag?
> > https://kernel.googlesource.com/pub/scm/linux/kernel/git/davem/net.git/+/
> >v3.19
> >
> >
> > I see that head is v4.0-rc4
> > I'm afraid that this might break other things.
> > I think of aufs, which I need to get my clients nfsroot booted.
>
> probably you can take a look on OverlayFS (instead of aufs) which
> was introduced in kernel 3.18
>
> Alex


Hi Alex,

Thank you for the tip.
But if it just were that easy as to have a look at it....

As far as I know, overlayfs only allows two layers, right?
So for more complex trees, I could maybe stack them (so I hope).

To do so, at least I had to redesign my complete script which builds the 
nfsroot mimics as shown below.

And as far as I could figure out, the representation of whiteouts is different 
in aufs and in overlayfs. So I cannnot simply use my existing aufs branches 
and stack them by overlayfs, without breaking the file/ whiteout consistency, 
or can I?


However, when making the decision in favour of aufs, the udba ("user direct 
branch access") feature (and lack thereof in overlayfs) was the main reason 
not to go for overlayfs:

> Changes to the underlying filesystems while part of a mounted overlay
> filesystem are not allowed.  If the underlying filesystem is changed,
> the behavior of the overlay is undefined,
( from https://www.kernel.org/doc/Documentation/filesystems/overlayfs.txt )

Is this going to change in the foreseeable future?
Are you aware of any plans to implement UDBA in overlayfs?
If so, I would be glad to participate in testing.

I could live without the udba feature for a limited test period.
But I got used to the possibility to install packages in a package layer, fine 
tune configuration in another layer and live test this on a parallel cluster 
of 16 machines, without dropping off nfsroot each time.

Maybe, part of this funcitonality can be replaced by btrfs snapshotting.
But nevertheless, it would end up as a comlepte redesign of my cluster setup.


Wolfgang Rosner



############################################################################

This is how my aufs mounts look like:

aufs-nfsroot-blade-001 on /cluster/nfs/nfsr/blade-001.crunchnet type aufs 
(rw,relatime,si=88a4f4d462df4343)
        0 rw id=64 path=/cluster/node_roots/wheezy-HD-2015_02_21/cow/cow_001
        1 ro+wh id=65 path=/cluster/node_roots/wheezy-HD-2015_02_21/config
        2 ro+wh id=66 path=/cluster/node_roots/wheezy-HD-2015_02_21/mask
        3 ro+wh id=67 path=/cluster/node_roots/wheezy-HD-2015_02_21/pkg_std
        4 ro id=68 path=/cluster/node_roots/wheezy-HD-2015_02_21/base
        xino: /tmp/.aufs.xino
	:
	(repeated 16 times)
	:
aufs-nfsroot-blade-016



plus 3 admin layers (writable for each intermediary layer)



root@...ncher:/cluster/etc/scripts/available# mount | grep aufs
aufs-nfsroot-blade-001 on /cluster/nfs/nfsr/blade-001.crunchnet type aufs 
(rw,relatime,si=88a4f4d462df4343)
aufs-nfsroot-blade-002 on /cluster/nfs/nfsr/blade-002.crunchnet type aufs 
(rw,relatime,si=88a4f4d3fe245343)
aufs-nfsroot-blade-003 on /cluster/nfs/nfsr/blade-003.crunchnet type aufs 
(rw,relatime,si=88a4f4d3fe9c5343)
aufs-nfsroot-blade-004 on /cluster/nfs/nfsr/blade-004.crunchnet type aufs 
(rw,relatime,si=88a4f4d467b53343)
aufs-nfsroot-blade-005 on /cluster/nfs/nfsr/blade-005.crunchnet type aufs 
(rw,relatime,si=88a4f4d47db69343)
aufs-nfsroot-blade-006 on /cluster/nfs/nfsr/blade-006.crunchnet type aufs 
(rw,relatime,si=88a4f4d4630bb343)
aufs-nfsroot-blade-007 on /cluster/nfs/nfsr/blade-007.crunchnet type aufs 
(rw,relatime,si=88a4f4d4586cc343)
aufs-nfsroot-blade-008 on /cluster/nfs/nfsr/blade-008.crunchnet type aufs 
(rw,relatime,si=88a4f4d458689343)
aufs-nfsroot-blade-009 on /cluster/nfs/nfsr/blade-009.crunchnet type aufs 
(rw,relatime,si=88a4f4d3fda97343)
aufs-nfsroot-blade-010 on /cluster/nfs/nfsr/blade-010.crunchnet type aufs 
(rw,relatime,si=88a4f4d3fe3be343)
aufs-nfsroot-blade-011 on /cluster/nfs/nfsr/blade-011.crunchnet type aufs 
(rw,relatime,si=88a4f4d3fe8cb343)
aufs-nfsroot-blade-012 on /cluster/nfs/nfsr/blade-012.crunchnet type aufs 
(rw,relatime,si=88a4f4d3fc90c343)
aufs-nfsroot-blade-013 on /cluster/nfs/nfsr/blade-013.crunchnet type aufs 
(rw,relatime,si=88a4f4d4622fb343)
aufs-nfsroot-blade-014 on /cluster/nfs/nfsr/blade-014.crunchnet type aufs 
(rw,relatime,si=88a4f4d3e2cc8343)
aufs-nfsroot-blade-015 on /cluster/nfs/nfsr/blade-015.crunchnet type aufs 
(rw,relatime,si=88a4f4d0ca64e343)
aufs-nfsroot-blade-016 on /cluster/nfs/nfsr/blade-016.crunchnet type aufs 
(rw,relatime,si=88a4f4d0ca92e343)
aufs_pkg_std on /cluster/node_roots/wheezy-HD-2015_02_21/admount-pkg_std type 
aufs (rw,relatime,si=88a4f4d46dced343)
aufs_mask on /cluster/node_roots/wheezy-HD-2015_02_21/admount-mask type aufs 
(rw,relatime,si=88a4f4d3b0a2b343)
aufs_config on /cluster/node_roots/wheezy-HD-2015_02_21/admount-config type 
aufs (rw,relatime,si=88a4f4d3fee4c343)







--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists