- Wednesday, January 4, 2017

release-team@conference.openafs.org

Wednesday, January 4, 2017< ^ >

Room Configuration

Room Occupants

GMT+0
[13:49:46] mvita leaves the room
[13:49:46] mvita joins the room
[14:44:19] meffie joins the room
[14:56:36] jgorse joins the room
[15:01:29] <mvita> happy new year!
[15:02:01] <jgorse> happy new year =)
[15:03:45] wiesand joins the room
[15:03:58] <mvita> yay Stephan is here
[15:04:05] <wiesand> Sorry for being late.
[15:04:17] <wiesand> Happy 2017 everyone!
[15:04:39] <mvita> you are right on time
[15:05:17] <wiesand> They're working on the lab's water supplies, so had to commute home.
[15:05:40] <wiesand> This also means I'm on a slow link. Please be ven more patient with me than usual ;-)
[15:05:53] <mvita> ok
[15:06:16] <kadukoafs@gmail.com/barnowlE45450E9> Happy belated new year!
[15:06:25] <mvita> hi Ben
[15:06:55] <wiesand> So… Linux 4.10-rc was released a few days ago. Any news whether we'll have to cope with anything?
[15:07:06] <mvita> yes
[15:07:11] <mvita> rc1 was fine
[15:07:18] <mvita> there is coping needed for rc2
[15:07:28] <mvita> I don't have it all worked out yet
[15:07:54] <wiesand> Yuck. But thanks a lot for caring!
[15:08:18] <mvita> it is dentry plumbing, of course, so double yuk
[15:08:28] <wiesand> This kind of dictates the 1.6.21 schedule I think.
[15:09:15] <wiesand> So we shouldn't be too ambtious.
[15:09:29] <mvita> not until I have some better understanding
[15:09:51] <wiesand> er, which statement?
[15:09:53] <mvita> I did a lot of research yesterday
[15:10:12] <mvita> > we shouldn't be too ambitious
[15:10:42] <mvita> …. about 4.10 support being available any time soon unless I can get a better understanding of what the right fix is in this case
[15:11:15] <wiesand> Ah. Sounds scary. What's "the case"?
[15:11:26] <wiesand> (for dummies, please)
[15:11:27] <mvita> have_submounts routine has gone away
[15:11:41] <mvita> it has a replacement, path_has_submounts
[15:11:46] <mvita> with different semantics
[15:12:06] <mvita> but it's not clear we should ever have been calling have_submounts in the first place
[15:12:53] <mvita> maybe one of you knows:  is it possible to mount another filesystem at a linux mountpoint somewhere in /afs filespace?
[15:12:54] <jgorse> mvita: I have some fancy shiny tools to tell you if it is called without adding code
[15:13:04] <jgorse> fwiw
[15:13:34] <mvita> oh, it's definitely called … from afs_linux_dentry_revalidate
[15:13:45] <kadukoafs@gmail.com/barnowlE45450E9> You mean like 'mount /dev/sdb1
/afs/athena.mit.edu/user/k/a/kaduk/mymountpoint'?
[15:13:46] <wiesand> let me try...
[15:13:57] <mvita> yes, does that work?
[15:14:17] <kadukoafs@gmail.com/barnowlE45450E9> I don't actually know, but I kind of expect it to succeed and have
local-only effect.
[15:14:43] <mvita> I spent a lot of time yesterday reading about mount namespaces
[15:15:23] <mvita> kAFS uses this to implement AFS mountpoints, by the way - it is quite elegant
[15:16:40] <kadukoafs@gmail.com/barnowlE45450E9> Arguably we should make AFS volume mounts into proper linux kernel
mounts, too, but no one has done the work (that I know of) and it
probably ends up being messy, especially w.r.t. having the same volume
mounted at multiple places in the hierarchy.
[15:16:42] <wiesand> Works,. At least loop-mounting does.
[15:16:44] <mvita> so for kAFS, each AFS mountpoint is a genuine linux submount
[15:17:12] <meffie> yep.
[15:17:19] <mvita> stephan, I don't understand the terminology:  loop mount, bind mount
[15:17:23] <wiesand> There;s a stack of changes in gerrit for 1.6, from Andrew a while ago.
[15:17:36] <wiesand> That should at least be a very good starting point
[15:17:46] <jgorse> a mountpoint being /afs/athena.mit.edu <http://athena.mit.edu> ?
[15:17:55] <mvita> jgorse:  yes
[15:18:10] <mvita> that's one example
[15:18:46] <wiesand> Here;s what I tried:
[15:19:22] <wiesand> dd if=/dev/zero of=/tmp/xxx bs=1M count=512; mkfs.ext3 /tmp/xxx; mount -oloop /tmp/xxx ~wiesand/tmp/x
[15:19:37] <jgorse> I wonder how difficult it would be to sync kAFS and OpenAFS in this regard.
[15:19:39] <wiesand> Where ~wiesand/tmp/x is a directory in AFS
[15:19:55] <kadukoafs@gmail.com/barnowlE45450E9> The loopback mount would just be using a file as the backing store
instead of a "real" device, IIUC.
[15:20:42] <mvita> jgorse:  I suspect (but have not confirmed) that the automounting stuff on which this is based requires RCU, which is GPL-only
[15:20:49] <wiesand> Right. A file in a filesystem on a mounted block device. This shouldn't differ in behaviour from mounting a block device directly.
[15:21:01] <mvita> OH
[15:21:09] <mvita> that's what loopback means?
[15:21:19] <mvita> what an odd name for that concept
[15:22:03] <kadukoafs@gmail.com/barnowlE45450E9> The filesystem code has to "loop back" onto another file system in
order to fulfil the requested operation.
[15:22:32] <mvita> thanks, that helps
[15:22:42] <mvita> how about bind mount?
[15:22:46] <wiesand> It's pretty useful sometimes. Want to try whether you app copes with a 4TB filesystem? Just create an fs on a sparse file and loop-mount it. ..
[15:22:56] <mvita> what does the term "bind" signify?
[15:23:29] <wiesand> that you "mount —bind"
[15:23:40] <mvita> sure, but…  ;-)
[15:23:48] <wiesand> seriously though, it's more like a redirection
[15:24:07] <kadukoafs@gmail.com/barnowlE45450E9> Bind mount is sort of like cloning the mounted filesystem, so that it
can be accessed from two different paths on the host.  "make a binding
between accesses from this hierarchy and accesses from the actual
hierarchy, and route them to the same backing store"
[15:24:28] <wiesand> mount —bind /tmp ~wiesand/tmp/x
[15:24:33] <wiesand> and yes that works too
[15:24:52] <mvita> okay - I did somewhat understand what it did, but now I understand why it's called "bind"
[15:25:20] <kadukoafs@gmail.com/barnowlE45450E9> "It makes perfect sense, if you already know what it means" :-/
[15:25:35] <mvita> TM
[15:25:56] <meffie> heh
[15:26:06] <wiesand> it's vocabulary… lots of terms we're used to have weird origins
[15:26:12] <wiesand> "logging"
[15:27:12] <mvita> that's an easy one - it refers back to all the trees sacrificed to the teletype printout
[15:27:16] <kadukoafs@gmail.com/barnowlE45450E9> TIMMMMMMMMMBBBEEEEEEEERRRRRRRRRR
[15:27:44] <wiesand> "It makes perfect sense, if you already know what it means"
[15:28:43] <wiesand> Was the term logbook used on ships before there were computers?
[15:29:01] <mvita> probably that's the true origin
[15:29:10] <mvita> rather than my farcical one above
[15:30:43] <wiesand> Anyway, looks like we support mount points (classical ones, not those symlinks interpreted as AFS mount points) in AFS space today.
[15:31:11] <mvita> okay, thank you - so in the past we really did want to call have_submounts
[15:31:39] <wiesand> BUT I wonder whether that's a crucial featrue we couldn't sacrifice if that's required to cope with Lunyx 4.10+
[15:31:46] <mvita> I don't think so any more - I think the VFS layer protects us from invalidating a path to a submount
[15:31:56] <mvita> but that's what I have to confirm
[15:32:05] <kadukoafs@gmail.com/barnowlE45450E9> That ought to be the VFS's job, yes.
[15:32:19] <kadukoafs@gmail.com/barnowlE45450E9> But "ought to" and "is" are not always the same thing :)
[15:33:22] <mvita> I'll keep researching and let you know what I find
[15:33:30] <wiesand> Thanks!
[15:35:04] <kadukoafs@gmail.com/barnowlE45450E9> Yes, thanks!
[15:35:33] <wiesand> NB Andrew's work sit in https://gerrit.openafs.org/#/q/status:open+project:openafs+branch:openafs-stable-1_6_x+topic:linux-mtpt-bindmount
[15:36:04] <mvita> oh, I was unaware of any of this
[15:37:48] <wiesand> This would solve the fundamental problem that Linux "knows" there;s only one path to an object in an fs, which is just not true in AFS.
[15:38:36] <wiesand> It would kill a lot of pain I think.
[15:39:12] <wiesand> But I have no idea what it would take to get it ready.
[15:39:40] <wiesand> And at this point it should probably done for 1.8, not 1.6 anymore.
[15:40:18] <mvita> at any rate, as Andrew says, it would have to go to master first
[15:40:26] <mvita> not sure why he pushed this to 1.6.x
[15:41:15] <meffie> it looks like it was his work in progress, while working on the stable branch..
[15:41:41] <wiesand> So people could look at it or even try it in the context of a production ready release?
[15:42:19] <wiesand> I mean, lots of code on master/1.8 was developed for 1.6, then forward-ported to master...
[15:42:29] <meffie> yes
[15:45:16] <wiesand> Not much has happened regarding the other 1.6.21 topics between the years, which is hardly surprising.
[15:46:40] <kadukoafs@gmail.com/barnowlE45450E9> 1.8 got a bug report!
[15:47:15] <wiesand> Re-enabling "shake harder" would be nice. There are +1s from Ben. There are path conflicts with other changes on the wish list. I'll likely merge it soon unless there's negative review.
[15:47:27] <wiesand> And yes, let's go on to 1.8.
[15:48:12] <mvita> Okay
[15:48:56] <kadukoafs@gmail.com/barnowlE45450E9> I don't suppose anyone has looked into reproducing it already?
[15:49:50] <wiesand> sorry
[15:51:05] <wiesand> #133654, right?
[15:53:17] <kadukoafs@gmail.com/barnowlE45450E9> I think that's the one, yeah
[15:53:54] <mvita> hmm
[16:00:07] <wiesand> Ben, more on 1.8?
[16:00:19] <kadukoafs@gmail.com/barnowlE45450E9> Not exactly; I'm in another meeting anyway
[16:00:59] <wiesand> Anything else to discuss today?
[16:01:15] <mvita> Nothing from me, thank you.
[16:01:36] <wiesand> Let's adjourn then. Thanks a lot everyone!
[16:01:46] <mvita> thank you
[16:02:09] <wiesand> cu next week then
[16:02:11] wiesand leaves the room
[17:34:12] jgorse leaves the room
[20:41:05] meffie leaves the room
[20:49:13] jgorse joins the room
[21:26:17] jgorse leaves the room