Netdev List
 help / color / mirror / Atom feed
From: Wolfgang Rosner <wrosner@tirnet.de>
To: "Zimmermann, Alexander" <Alexander.Zimmermann@netapp.com>
Cc: "netdev@vger.kernel.org" <netdev@vger.kernel.org>
Subject: Re: One way TCP bottleneck over 6 x Gbit tecl aggregated link // Kernel issue
Date: Mon, 23 Mar 2015 14:54:57 +0100	[thread overview]
Message-ID: <201503231454.57319.wrosner@tirnet.de> (raw)
In-Reply-To: <8926B7EB-3EC1-404A-95BA-787DF248773E@netapp.com>

Am Montag, 23. März 2015 10:25:33 schrieben Sie:
> Hi Wolfgang,
>
> > Am 23.03.2015 um 10:05 schrieb Wolfgang Rosner <wrosner@tirnet.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@cruncher:/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)

  reply	other threads:[~2015-03-23 13:55 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-03-21  0:10 One way TCP bottleneck over 6 x Gbit tecl aggregated link Wolfgang Rosner
2015-03-21  1:15 ` Eric Dumazet
     [not found] ` <201503220912.39912.wrosner@tirnet.de>
     [not found]   ` <1427020159.25985.43.camel@edumazet-glaptop2.roam.corp.google.com>
2015-03-22 15:14     ` Wolfgang Rosner
2015-03-22 16:54       ` Eric Dumazet
2015-03-22 20:47         ` Wolfgang Rosner
2015-03-23  0:57           ` One way TCP bottleneck over 6 x Gbit tecl aggregated link // Kernel issue Wolfgang Rosner
2015-03-23  2:33             ` Eric Dumazet
2015-03-23  9:05               ` Wolfgang Rosner
2015-03-23  9:25                 ` Zimmermann, Alexander
2015-03-23 13:54                   ` Wolfgang Rosner [this message]
2015-03-24 12:59                     ` Zimmermann, Alexander
2015-03-26 19:34               ` Wolfgang Rosner
2015-03-27 18:46                 ` Wolfgang Rosner

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=201503231454.57319.wrosner@tirnet.de \
    --to=wrosner@tirnet.de \
    --cc=Alexander.Zimmermann@netapp.com \
    --cc=netdev@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox