summaryrefslogtreecommitdiff
path: root/hurd/translator/mtab
diff options
context:
space:
mode:
Diffstat (limited to 'hurd/translator/mtab')
-rw-r--r--hurd/translator/mtab/discussion.mdwn964
1 files changed, 945 insertions, 19 deletions
diff --git a/hurd/translator/mtab/discussion.mdwn b/hurd/translator/mtab/discussion.mdwn
index 0734e1e6..89593436 100644
--- a/hurd/translator/mtab/discussion.mdwn
+++ b/hurd/translator/mtab/discussion.mdwn
@@ -1,4 +1,4 @@
-[[!meta copyright="Copyright © 2008, 2009, 2013 Free Software Foundation,
+[[!meta copyright="Copyright © 2008, 2009, 2013, 2014 Free Software Foundation,
Inc."]]
[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
@@ -18,7 +18,7 @@ mounted file systems. This also means that commands like `df` can only work on
explicitly specified mountpoints, instead of displaying the usual listing.
One possible solution to this would be for the translator startup mechanism to
-update the `mtab` on any `mount`/`unmount`, like in traditional systems.
+update the `mtab` on any `mount`/`umount`, like in traditional systems.
However, there are some problems with this approach. Most notably: what to do
with passive translators, i.e., translators that are not presently running, but
set up to be started automatically whenever the node is accessed? Probably
@@ -1110,6 +1110,12 @@ In context of [[open_issues/mig_portable_rpc_declarations]].
e.g. http://darnassus.sceen.net/gitweb/?p=teythoon/hurd.git;a=shortlog;h=refs/heads/feature-mtab-translator-v3-wip
+### IRC, freenode, #hurd, 2013-11-20
+
+ <braunr> teythoon: ah thanks for making mtab multithreaded :)
+ <braunr> i forgot about that
+
+
## [[open_issues/libnetfs_passive_translators]]
@@ -1864,21 +1870,9 @@ In context of [[open_issues/mig_portable_rpc_declarations]].
<teythoon> and I saw that this also aplies to remap.sh
<teythoon> *while
<youpi> yep, they're basically the same
- <teythoon> btw, I somehow feel settrans is being abused for chroot and
- friends, there is no translator setting involved
- <youpi> chroot, the command? or the settrans option?
- <youpi> I don't understand what you are pointing at
- <teythoon> the settrans option being used by fakeroot, remap and (most
- likely) our chroot
- <youpi> our chroot is just a file_reparent call
- <youpi> fakeroot and remap do start a translator
- <teythoon> yes, but it is not being bound to a node, which is (how I
- understand it) what settrans does
- <teythoon> the point being that if settrans is being invoked with --chroot,
- it does something completely different (see the big if (chroot) {...}
- blocks)
- <teythoon> to a point that it might be better of in a separate command
- <youpi> Mmm, indeed, a lot of the options don't make sense for chroot
+
+[[open_issues/virtualization/remap_root_translator]],
+[[open_issues/virtualization/fakeroot]].
## IRC, freenode, #hurd, 2013-09-06
@@ -1973,6 +1967,9 @@ In context of [[open_issues/mig_portable_rpc_declarations]].
<teythoon> right, so now at last I got the whole question :)
<braunr> :)
<teythoon> ugh, I just found the FS_RETRY_MAGICAL handler in the libc :-/
+
+[[interface/dir_lookup]].
+
<braunr> ?
<braunr> why "ugh" ?
<teythoon> well, I'm inclined to think this is the bad kind of magic ;)
@@ -2103,7 +2100,173 @@ In context of [[open_issues/mig_portable_rpc_declarations]].
<youpi> anyway, got to run
-## IRC, freenode, #hurd, 2013-09-20
+## Memory Leak
+
+Fixed in 2013-09-28 Hurd commit a81c0c28ea606b0d0a2ad5eeb74071c746b7cdeb
+(libdiskfs), and 2013-10-04 Hurd commit
+98b6f846b628e858acbae9258bac78cf54126d27 (libnetfs).
+
+### IRC, freenode, #hurd, 2013-09-18
+
+ <braunr> ext2fs is using a ginormous amount of memory on darnassus since i
+ last updated the hurd package :/
+ <braunr> i wonder if my ext2fs large store patches rework have introduced a
+ regression
+ <braunr> the order of magnitude here is around 1.5G virtual space :/
+ <braunr> it used to take up to 3 times less before that
+ <braunr> looks like my patches didn't make it into the latest hurd package
+ <braunr> teythoon: looks like there definitely is a new leak in ext2fs
+ <teythoon> :/
+ <braunr> memory only
+ <braunr> the number of ports looks stable relative to file system usage
+ <teythoon> braunr: I tested my patches on my development machine, it's up
+ for 14 days (yay libvirt :) and never encountered problems like this
+ <braunr> i've been building glibc to reach that state
+ <teythoon> hm, that's a heavy load indeed
+ <teythoon> could be the file name tracking stuff, I tried to make sure that
+ everything is freed, but I might have missed something
+ <braunr> teythoon: simply running htop run shows a slight, regular increase
+ in physical memory usage in ext2fs
+ <pinotree> old procfs stikes again? :)
+ <teythoon> braunr: I see that as well... curious...
+ <braunr> 16:46 < teythoon> could be the file name tracking stuff, I tried
+ to make sure that everything is freed, but I might have missed something
+ <braunr> how knows, maybe completely unrelated
+ <teythoon> the tracking patch isn't that big, I've gone over it twice today
+ and it still seems reasonable to me
+ <braunr> hm
+
+
+### IRC, freenode, #hurd, 2013-09-25
+
+ <braunr> seems like a small leak per file access
+ <braunr> but htop makes it obvious because it makes lots of them
+ <braunr> shouldn't be too hard to find
+ <braunr> since it might also come from the large store patch, i'll take a
+ look at it
+
+
+### IRC, freenode, #hurd, 2013-09-27
+
+ <braunr> teythoon: found the leak :)
+ <braunr> although its origin is weird
+ <teythoon> braunr: where is it?
+ <braunr> i'm still building packages to make sure that's it
+ <braunr> see
+ http://darnassus.sceen.net/gitweb/savannah_mirror/hurd.git/blob/HEAD:/libdiskfs/dir-lookup.c
+ <braunr> which you changed in
+ http://darnassus.sceen.net/gitweb/savannah_mirror/hurd.git/commit/06d49cdadd9e96361f3fe49b9c940b88bb869284
+ <braunr> line 306 is "return error" instead of "goto out"
+ <braunr> has been so since 1994
+ <braunr> what is unclear is why this code path is now run
+ <braunr> patch is here:
+ http://darnassus.sceen.net/~rbraun/0001-Fix-memory-leak-in-libdiskfs.patch
+ <teythoon> I see, weird indeed
+ <braunr> teythoon: the system also feels slower somehow
+ <braunr> such errors might have introduced unexpected retries
+ <teythoon> i think it's possible to write a coccinelle patch to find such
+ errors
+
+
+### IRC, freenode, #hurd, 2013-09-28
+
+ <youpi> braunr: bah, I havent noticed the leak on my box, even after
+ building eglibc & hurd several times
+ <braunr> that's weird
+ <braunr> are you sure it's up to date ?
+ <braunr> also, is procfs correctly attached to /proc ?
+ <braunr> that's what seems to trigger it
+ <youpi> yes, 20130924-2, with procfs on /proc
+
+ <teythoon> braunr: that turned out to be the leak indeed? and somehow my
+ changes triggered it? did you discover why?
+ <braunr> teythoon: yes, yes, no
+ <braunr> but youpi didn't see the leak on his system
+ <teythoon> ^^ cool that you found it
+ <teythoon> I did
+ <braunr> oh yes you mean you saw the leak
+ <teythoon> yes
+
+
+### IRC, freenode, #hurd, 2013-10-01
+
+ <braunr> the fix i did in libdiskfs might have fixed other issues
+ <braunr> apparently, it's the code path taken when error isn't ENOENT,
+ including no error (translator started)
+ <pinotree> the memory leak fix, you mean?
+ <braunr> yes
+ <braunr> it might haved fixed reference counting too
+ <braunr> although i'm not sure if we actually ever run into that issue in
+ the past
+ <braunr> the weird thing is, that path is taken when starting a passive
+ translator
+ <braunr> (i think)
+ <braunr> (it might be any kind of translator, and just doing nothing if
+ alcready active)
+ <braunr> already*
+ <braunr> anyway, the fact that the leak was so visible means this code was
+ run very often
+ <braunr> which doesn't make sense
+ <braunr> hm ok, it seems that code was run every time actually
+ <braunr> but the leak became visible when it concerned memory
+ <pinotree> which side-effects did the old code produce?
+ <braunr> teythoon added a dynamically allocated path that wasn't freed
+ <braunr> reference leaks
+ <braunr> which might explain the assertion on reference we sometimes see
+ with ext2fs
+ <braunr> when a counter overflows and becomes 0
+
+[[open_issues/ext2fs_libports_reference_counting_assertion]]?
+
+ <pinotree> hmm
+ <braunr> which is why i'm mentioning it
+ <braunr> :)
+ <braunr> i'll try to reproduce the assertion
+ <braunr> pinotree: actually, after a more in-depth look, reference counting
+ looks valid before the fix too
+ <pinotree> ok, thanks for checking
+ <braunr> pinotree: the assertion affects the root translator, and is
+ triggered by a test that stresses memory
+ <pinotree> memory as in ram, or as in disk storage?
+ <braunr> malloc
+ <pinotree> ok
+ <braunr> i suspect the code doesn't handle memory failure well
+
+
+### IRC, freenode, #hurd, 2013-10-02
+
+ <teythoon_> braunr: btw, did you fix the leak?
+ <braunr> yes
+ <braunr>
+ http://darnassus.sceen.net/gitweb/savannah_mirror/hurd.git/commit/a81c0c28ea606b0d0a2ad5eeb74071c746b7cdeb
+ <braunr> 1h after tagging 0.5 (
+ <braunr> :(
+ <teythoon> ah yes, I've seen that commit
+ <teythoon> I just wanted to know whether this settled the issue
+ <braunr> it does :)
+ <teythoon> good
+ <braunr> i still can't figure out why youpi didn't had it
+ <braunr> the code path is run when no error (actually error != ENOENT)
+ <braunr> which explains why the leak was so visible
+ <teythoon> so my patch exposed this b/c of the allocation I added, makes
+ sense
+ <teythoon> it's funny actually, b/c this wasn't an issue for me as well, I
+ had my development vm running on that patches for two weeks
+
+
+### IRC, freenode, #hurd, 2013-10-02
+
+ <braunr> libnetfs suffers from the same leak as libdiskfs when looking up a
+ translator
+ <braunr> i'll fix it too
+
+
+## Multiple mtab Translators Spawned
+
+Fixed in 2013-10-05 procfs commit c87688a05a8b49479ee10127470cc60acebead4a?
+
+
+### IRC, freenode, #hurd, 2013-09-20
<braunr> teythoon: how come i see three mtab translators running ?
<braunr> 6 now oO
@@ -2113,10 +2276,773 @@ In context of [[open_issues/mig_portable_rpc_declarations]].
<braunr> teythoon: more bug fixing for you :)
-## IRC, freenode, #hurd, 2013-09-23
+### IRC, freenode, #hurd, 2013-09-23
<teythoon> so it might be a problem with either libnetfs (which afaics has
never supported passive translator records before) or procfs, but tbh I
haven't investigated this yet
[[open_issues/libnetfs_passive_translators]].
+
+
+### [[!debbug 724868]]
+
+
+### IRC, freenode, #hurd, 2013-10-03
+
+ <braunr> i can't manage to find out where the hurd stores information about
+ active translators ...
+ <braunr> there is this transbox per node
+ <braunr> but where are nodes stored ?
+ <braunr> what if they are are dropped ?
+ <pinotree> braunr: iirc, see libfshelp
+ <braunr> well i have
+ <braunr> i still can't find it
+ <braunr> i fear that it works for ext2fs because that particular translator
+ implements a cache of open nodes
+ <braunr> whereas things like procfs drop and recreate nodes per open
+ <braunr> which would be the root cause for the multiple mtab bug
+ <pinotree> doesn't tmpfs support translators?
+ <braunr> good idea
+ <braunr> although it's still a libdiskfs based one
+ <braunr> no problem for tmpfs, so it would be a netfs/procfs issue
+ <braunr> better than what i feared :)
+ <braunr> now, how is libdiskfs able to find active translators ..
+ <braunr> ah, there is a name cache in libdiskfs ..
+ <braunr> nope, looks fine
+
+
+### IRC, freenode, #hurd, 2013-10-04
+
+ <braunr> nodes with a translator seem to keep a reference in libdiskfs and
+ not in libnetfs
+ <braunr> mhmmpf
+ <braunr> oh great ..
+ <braunr> each libdiskfs that "works" seems to implement its own
+ diskfs_cached_lookup function
+ <braunr> so both ext2fs and tmpfs actually maintain a list of nodes,
+ keeping a reference on those with a translator
+ <braunr> while procfs simply doesn't
+ <braunr> teythoon: ^
+ <braunr> *sigh*
+ <teythoon> braunr: ok, thanks, I'll look into that
+ <braunr> i'm not sure how to fix it
+ <braunr> we can either fix node destruction to cleanly shut down
+ translators
+ <braunr> but this would mean starting mtab on each access
+ <braunr> or we could implement a custom cache in procfs
+ <braunr> or perhaps a very custom change in the lookup callback for mounts
+ <braunr> i'll try the latter
+ <teythoon> err, shouldn't we try to fix this in lib*fs?
+ <braunr> unless you really want to work on it
+ <braunr> i dont' know
+ <teythoon> ah, so the node is destroyed but the translator is kept running?
+ that's what you mean by the above?
+ <teythoon> and ext2fs makes an effort of killing it in its node cleanup
+ code?
+ <braunr> yes
+ <braunr> grmbl, i'm lagging a lot
+ <braunr> i'm not sure
+ <braunr> ext2fs maintains it
+ <braunr> with ext2fs, translators can only be explicitely removed
+ <braunr> i mean, ext2fs keeps all node descriptors alive once accessed
+ <braunr> while procfs doesn't
+ <braunr> teythoon: ok, looks like i have a working patch that merely caches
+ the node for mounts
+
+ <braunr> i installed my fixed procfs on darnassus, only one mtab :)
+ <teythoon> nice :)
+
+ <braunr> i have a fix for the multiple mtab issue, will send a patch
+ tonight
+
+
+## `/home` Missing
+
+### IRC, freenode, #hurd, 2013-10-04
+
+ <braunr> now, why is there no /home in df output ?
+ <teythoon> not sure
+ <teythoon> note how /dev/tty* end up in /proc/mounts, those are passive
+ translators too, no?
+ <braunr> yes
+ <braunr> but that's a good thing i guess
+ <braunr> or was mounts intended for file systems only ?
+ <braunr> well, in the unix traditional meaning
+ <teythoon> I think its nice too, yes
+ <teythoon> but why are they fine and your /home is not...
+ <braunr> that's weirder
+ <braunr> also, mounts actually doesn't show passive translators
+ <braunr> teythoon: does your code perform any kind of comparison ?
+ <braunr> i see /servers/socket/26 but not /servers/socket/2
+ <braunr> s/comparison/filter/g
+ <teythoon> hmm
+ <teythoon> well, yes, try /hurd/mtab --insecure /
+ <teythoon> (I cannot connect to darnassus from here...)
+ <braunr> ok but that looks unrelated
+ <braunr> both /servers/socket/26 and /servers/socket/2 refer to the same
+ translator
+ <braunr> i was wondering if mtab was filtering similar entries based on
+ that
+ <teythoon> no
+ <braunr> that's weird too then, isn't it ?
+ <teythoon> yes ;)
+ <braunr> ok
+ <teythoon> btw, how is that done with the same traanslator being bound to
+ two nodes? settrans cannot do that, can it?
+ <braunr> no it can't
+ <braunr> the translator does it when started
+ <teythoon> ah
+ <braunr> (which means there is a race if both are started simulatneously,
+ although it's very rare and not hard to solve)
+ <teythoon> a weird beaving translator then :)
+
+ <braunr> teythoon: if ext2fs is set active, mtab output reports it
+
+ <braunr> teythoon: looks like this bug is what allows mtab not to deadlock
+ <braunr> teythoon: when i attach it as an active translator, cat freezes
+
+ <braunr> teythoon: if (control && control->pi.port_right == fsys)
+ <braunr> that's the filtering i was previously talking about
+
+ <braunr> oh please don't name global variables "path" ...
+
+
+### IRC, freenode, #hurd, 2013-10-06
+
+ <antrik> teythoon: pty-s also bind to two nodes, not only pfinet
+
+
+### IRC, freenode, #hurd, 2013-10-07
+
+ <braunr> teythoon: please tell us when you're available, we need to work
+ out the last mtab issues
+ <teythoon> braunr: I'm available now :)
+ <teythoon> I'm sorry, I've been very busy the last two weeks, but I've
+ plenty of time now
+ <braunr> great :)
+ <braunr> did you see youpi's mail ?
+ <braunr> i have the exact same question
+ <teythoon> I did
+ <braunr> it seems your code registers active translators
+ <braunr> but parent translators don't seem to register them when they're
+ created from passive translators
+ <braunr> or am i mistaken ?
+ <teythoon> I'll need a moment to get my hurd machine and myself up to
+ speed...
+ <teythoon> braunr: I concur with youpi, hooking into fshelp_fetch_root
+ should do just fine
+ <teythoon> I'll just try that
+ <braunr> ok
+ <braunr> how do you deal with mtab reporting itself ?
+ <teythoon> o_O does it do that?
+ <braunr> no, but it should
+ <braunr> when i set it as an active translator, i get a deadlock
+ <braunr> hm
+ <braunr> teythoon: before you change libfshelp, i'd like you to try
+ something else
+ <braunr> use more appropriate names for global variables in mtab.c
+ <braunr> in particular, the variable path clashes with local names
+ <teythoon> noted
+ <braunr> teythoon: as a side note (i'm not asking to rewrite anything)
+ <braunr> i strongly recommend a very explicit object oriented style of
+ coding
+ <braunr> (or data-oriented as it's sometimes called)
+ <braunr> use prefixes for all your interfaces so they can be made public if
+ needed (which acts as a namespace and avoids lots of collisions
+ naturally)
+ <braunr> use "constructors" and "destructors" (functions that both allocate
+ and initialize)
+ <braunr> this helps avoiding leaks a lot too
+ <teythoon> hm, I thought I did that, could you be more specific?
+ <braunr> ok didn't see the comment
+ <braunr> /* XXX split up */ error_t mtab_populate (...
+ <braunr> :)
+ <braunr> as a better example, see your code in libfshelp/translator-list.c
+ <braunr> struct translator should have been treated as an object
+ <braunr> this would probably have completely avoided any leaks in the first
+ place
+ <teythoon> braunr: right, I deviated from that style there
+ <braunr> teythoon: these are minor details, don't mind them too much, i
+ just find it helps me a lot
+ <teythoon> braunr: sure, I appreciate the feedback :)
+
+
+### IRC, freenode, #hurd, 2013-10-08
+
+ <teythoon> braunr: I'm on to the passive translator not getting registered
+ issue
+ <teythoon> however, removing them from the list if the active translator is
+ killed does not work as expected... I still need to fiddle with the
+ notifications to get this right
+ <braunr> ok
+
+
+### IRC, freenode, #hurd, 2013-10-16
+
+ <teythoon> braunr: btw, I fixed the 'passive translator not showing up in
+ proc/mounts'-issue
+ <teythoon> but 4 ports do leak each time a translator is killed and
+ reinstalled
+ <teythoon> this happens with passive ones as well as active ones
+ <braunr> teythoon: is that issue tied to your changed ?
+ <braunr> changes*
+ <teythoon> I'm not sure tbh, testing that is on my list of things to do
+ <braunr> ok
+ <braunr> first thing to know i guess
+ <teythoon> yes
+
+
+### IRC, freenode, #hurd, 2013-11-06
+
+ <braunr> by the way, did you fix mtab for passive translators ?
+ <braunr> or make any progress ?
+ <teythoon> I just cleaned up the patch series
+ <braunr> ah good
+ <teythoon> I'm still trying to decide whether I leak any ports
+
+
+### IRC, freenode, #hurd, 2013-11-15
+
+ <teythoon> btw, I haven't forgotten about the passive translator not
+ showing up in /proc/mounts
+ <teythoon> I have a patch series, the first patch seems fine, but if I
+ build hurd packages with the other two (those that actually hook into
+ dir-lookup), strange things happen
+ <teythoon> on the first boot, everything is fine, passive translators
+ showing up in /proc/mounts, nice
+ <teythoon> but when I reboot, the system kind-of comes back, but something
+ is very wrong with many (passive?) translators
+ <teythoon> the system never recovers, I have no idea whats going on there
+ <braunr> ok
+ <braunr> push that work in a branch somewhere for review please
+ <teythoon> right, thanks
+ <teythoon> braunr:
+ http://darnassus.sceen.net/gitweb/teythoon/hurd.git/shortlog/refs/heads/feature-translatorslist-detect-passive-translators
+
+
+### IRC, freenode, #hurd, 2014-01-04
+
+ <youpi> teythoon: did you eventually get any idea about why /proc/mounts is
+ missing mounts?
+ <youpi> e.g. I have /boot as a separate partition, it doesn't show up
+
+
+### IRC, freenode, #hurd, 2014-01-05
+
+ <teythoon> youpi: yes, passive translators are not currently handled
+ <teythoon> youpi: i have patches for that, but they produce weird results,
+ braunr promised to take a look
+ <braunr> teythoon: hum
+ <teythoon> ^^
+ <braunr> i thought they were pending review
+ <braunr> !
+ <braunr> where are they again ?
+ <teythoon>
+ http://darnassus.sceen.net/gitweb/teythoon/hurd.git/shortlog/refs/heads/feature-translatorslist-detect-passive-translators
+ <braunr> ok
+ <teythoon> they are reasonably straight-forward
+ <teythoon> but cause this funny issue, after the first reboot with the
+ patched hurd everything is fine
+ <teythoon> after the second reboot, everything is weird and broken badly
+ <braunr> right
+ <braunr> interesting :)
+
+
+### IRC, freenode, #hurd, 2014-01-06
+
+ <braunr> teythoon: is it normal that, if ext2fs is started as an active
+ translator for /home, and then for another directory inside my home, mtab
+ only reports / and /home and not this third file system ?
+ <braunr> (with the hurd master version)
+ <braunr> (the translator for /home is run by root, but the one inside my
+ home is started with my uid)
+ <braunr> (and every component on the path is readable/crossable)
+
+
+### IRC, freenode, #hurd, 2014-01-07
+
+ <teythoon_> braunr: well yes, the mtab tool/translator does not follow
+ translators bound to nodes not owned by root
+ <teythoon> braunr: try /hurd/mtab --insecure /home
+ <braunr> ok
+ <braunr> good thinking
+
+ <teythoon> braunr: did you encounter any problems after the second reboot ?
+ <braunr> i'm not yet there
+ <braunr> work still making me busy
+ <braunr> and i'm trying to isolate the problem first
+ <braunr> that is, restrict tests to a single leaf translator
+ <teythoon> you reproduced the weirdness ?
+ <braunr> teythoon: attempting
+ <braunr> teythoon: first i'm trying to check a few things
+ <braunr> teythoon: i'm running my leaf translator as root now
+ <braunr> active
+ <braunr> and i still don't see it :/
+ <braunr> one of the components in the path is not own by root
+ <braunr> is that a problem ?
+ <teythoon> no, but maybe the mtab translator should check for that...
+ <braunr> does it check for the node ownership or the process rights ?
+ <braunr> credentials, rather
+ <teythoon> node ownership
+ <braunr> ah, ok
+ <braunr> ok i see it now
+ <braunr> oh, also, it looks like settrans -g on an active translator
+ doesn't work, i get ebusy all the time :/
+ <teythoon> oh ?
+ <teythoon> that could explain the fs corruption i saw
+ <teythoon> did i break that ?
+ <braunr> i don't know
+ <braunr> maybe
+ <braunr> i think it was possible in the past
+
+ <braunr> teythoon: when isolated, your code works fine
+ <braunr> i'll try applying it globally
+ <braunr> btw, how did you do that ?
+ <braunr> through debian packages ?
+ <teythoon> i'm trying to get to the point, but i'm still not there
+ <teythoon> with our uber-buildbot setup i picture myself pushing to a git
+ repo, wait a little and get the packages from my deb repo...
+ <teythoon> for now, i have my hurdtest tool that i used during gsoc
+ <teythoon> with that i can just drop files into a directory and have that
+ overlayed ontop of my test image
+ <braunr> hum
+ <braunr> so you replaced the lib*fs libraries directly ?
+ <braunr> and the static rootfs ?
+ <teythoon> yes
+ * teythoon checks
+ <teythoon> hm, maybe i just missed a file, not sure anymore
+
+ <braunr> teythoon: with the new libraries, df -h doesn't see passive
+ translators :/
+ <teythoon> braunr: see /proc/mounts please
+ <braunr> same
+ <teythoon> or /hurd/mtab /
+ <teythoon> weird
+ <braunr> no :/
+ <teythoon> b/c when i developed it, i used a test suite to check that every
+ combination of tmpfs/ext2fs active/passive and every way to get rid of
+ any translator produced the desired results
+ <teythoon> i'll look into this
+ <braunr> teythoon: when i remove the active translator i set on /home, i
+ get
+ <braunr> /dev/hd0s1 8.1G 2.0G 5.8G 26% /home
+ <braunr> hd0s1 being used for / :/
+ <braunr> this does need reviewing
+ <teythoon> this is how i expect the system to react currently
+ <braunr> oh
+ <teythoon> w/o these patches
+ <braunr> hm ok
+ <braunr> well
+ <braunr> i'm currently using them
+ <teythoon> including the root fs ?
+ <braunr> yes
+ <teythoon> hmpf
+ <braunr> i have to mention that i merged master into it
+ <teythoon> i did the same
+ <teythoon> currently compiling...
+ <braunr> i only changed libdiskfs, libnetfs and libfshelp
+ <braunr> is there something else that should be changed ?
+ <braunr> (i.e. because of inlining ?)
+ <braunr> i guess i should rebuild a hurd package just to be sure
+ <kilobug> braunr: isn't the translator for / statically linked ? if so it
+ needs to be rebuilt (sorry if I'm saying silly things by popping out of
+ nowhere)
+ <braunr> yes i took care of that
+
+ <braunr> teythoon: i've built a hurd package with the three patches and i
+ don't see passive translators at all
+ <teythoon> :/
+ <braunr> well
+ <braunr> actually i see a lot of the
+ <braunr> them
+ <braunr> just not /home
+
+ <teythoon> braunr: please see
+ /home/teythoon/build/hurd-upstream/test.{bash,log}
+ <teythoon> the latter is a log i just created on darnassus
+ <teythoon> it shows no failures
+ <teythoon> do you have another translator that is started from a passive
+ translator record ?
+ <teythoon> besides /home, if so, does that show up ?
+ <braunr> well, as i just said, i can actually see many of them
+ <teythoon> weird
+ <braunr> http://darnassus.sceen.net/~rbraun/mounts
+ <braunr> hm
+ <braunr> let's try without --sync=
+ <braunr> ah, now i can see it
+ <teythoon> can you give me the command line you used before
+ <teythoon> for the /home translator
+ <braunr> /hurd/ext2fs --sync=30 /dev/hd0s6
+ <braunr> but hm
+ <braunr> i can only see /home when the passive translator is started
+ <braunr> is that intentional ?
+ <teythoon> yes
+ <braunr> ok
+ <teythoon> and it doesn't work with --sync=30 o_O
+ <braunr> so, actually, mtab doesn't report passive translators
+ <teythoon> no
+ <braunr> it reports active ones only, whether they're started manually or
+ from passive translators
+ <teythoon> yes
+ <braunr> ok
+ <braunr> that's good enough
+ <braunr> reporting passive translators wouldprobably require a complete
+ scan
+ <teythoon> yes, that was deemed not feasible
+ <braunr> right
+ <braunr> i can't reproduce any weirdness
+ <teythoon> good
+ <braunr> it seems to just work well
+ <braunr> except this option parsing problem
+ <teythoon> thanks for looking into this
+ <teythoon> yeah
+ <braunr> sur
+ <braunr> e
+ <braunr> thanks for reminding me :)
+ <teythoon> the actual fix is implementing fsys_get_source
+ <braunr> i forgot that "pending review" was my review here he
+ <teythoon> which should actually be file_get_source
+
+ <braunr> teythoon: why does mtab report errors for /proc/swaps and
+ /xconsole ?
+ <teythoon> not sure
+
+ <teythoon> btw, i build hurd packages with my patches and it reliably
+ wreaks havoc on my test vms ...
+ <braunr> now that's really weird
+ <braunr> are you certain everything has been cleaned since your manual
+ replacement of the libraries ?
+ <teythoon> yes, i use mainly throwaway-vms for such experiments
+ <braunr> ok
+ <teythoon> did you include the debian patches ?
+ <braunr> yes
+ <teythoon> so did i
+ <braunr> i based my work on my own packages
+ <braunr> with thread destruction
+ <braunr> i'll redo it from the sid ones
+ <braunr> but before, i guess i should share mine with you
+ <braunr> so you can test them in your vms
+ <braunr> we may simply have different configurations
+ <teythoon> yes
+ <braunr> something we might have missed just like the --sync parameter
+
+
+### IRC, freenode, #hurd, 2014-01-08
+
+ <braunr> teythoon: hello
+ <braunr> see http://darnassus.sceen.net/~rbraun/teythoon/ for the custom
+ hurd packages
+ <braunr> they need thread destruction so get the latest gnumach package
+ from unstable, and the libc packages from my repository first
+
+
+### IRC, freenode, #hurd, 2014-01-09
+
+ <teythoon> braunr: your packages indeed seem to work
+ <teythoon> and with mine i encounter a different problem, the proc server
+ crashes *very* early
+ <teythoon> this is w/o a rebuilt libc
+ <teythoon> different as in not the weird one i remember having back when i
+ wrote those patches
+ <braunr> hum
+ <braunr> you're using all my glibc/hurd packages right ?
+ <teythoon> your packages work fine
+ <braunr> i wonder if your bug is caused by
+ 2c9422595f41635e2f4f7ef1afb7eece9001feae
+ <teythoon> mine don't
+ <braunr> (or rather, not having it)
+ <braunr> look at the patches i've added
+ <braunr> it's included, and i remember i really needed it
+ <braunr> althouhg it was just about a leak
+ <braunr> hm
+ <braunr> i don't know :/
+ <braunr> but i strongly suspect your patches are ok
+ <braunr> and something else is wrong
+ <teythoon> why would my packages miss that patch ?
+ <braunr> hum
+ <braunr> are you testing with your packages built from upstream sources ?
+ <teythoon> always
+ <braunr> upstream hurd against debian glibc ?
+ <teythoon> yes
+ <braunr> check the patches again
+ <teythoon> what patches ?
+ <braunr> the debian ones that you don't include
+ <braunr> another thing you can do is
+ <teythoon> err
+ <braunr> get the latest debian hurd package
+ <braunr> add your patch only
+ <braunr> rebuild
+ <teythoon> i use hurd upstream + all the debian stuff
+ <braunr> that's weird
+ <braunr> but hurd upstream has received quite a lot of patches
+ <braunr> please try from debian hurd + your patch only
+
+ <teythoon> braunr: i'm afraid it might be your patch 3a3fcc81 that breaks
+ proc
+
+[[open_issues/libpthread_set_stack_size]].
+
+ <braunr> teythoon: but anyway, it does look like your patches are actually
+ fine
+ <teythoon> yes
+ <braunr> i'll install my packages on darnassus and test a bit more
+ <teythoon> there is an issue however
+ <braunr> ah
+ <teythoon> grep sd2s1 /proc/mounts
+ <teythoon> /dev/sd2s1 /dev/sd2s1 /hurd/storeio writable 0 0
+ <teythoon> that makes fsck think that /dev/sd2s1 is mounted
+ <braunr> hmpf
+ <teythoon> which makes debians fsck magic (when using sysvinit) drop to a
+ root shell at boot time
+ <braunr> why does it report a mount point ?
+ <braunr> or even a device
+ <braunr> why not none /dev/sd2s1 ?
+ <teythoon> b/c of the heuristic it uses
+ <teythoon> and i know, you told me it's a bad idea
+ <braunr> i did ?
+ <teythoon> probably
+ <braunr> hm
+ <braunr> we said so many things i don't remember
+ <braunr> but that doesn't look too hard to fix
+ <teythoon> well, i'll just have to make translators provide meaningful
+ get_source responses
+ <teythoon> and get rid of the heuristic
+ <braunr> ok
+ <teythoon> so if you use passive translators for the mounts, and not
+ /etc/fstab, you should be fine
+ <teythoon> my "traditional" hurd systems are
+ <braunr> teythoon: i'll wait a bit before deplying it on darnassus then
+
+
+### IRC, freenode, #hurd, 2014-01-13
+
+ <braunr> teythoon: does your latest patch series take care of --sync ?
+ <teythoon> yeah, i finally got why the hurd would react strangely after an
+ reboot, it was umount --all removing vital passive translator records
+ <teythoon> i never had any issues with --sync
+ <braunr> ah, umount -a
+ <braunr> hm
+ <braunr> do you recall i did :) ?
+ <teythoon> umount -a was only run with the sysvinit scripts, that's why you
+ didn't see that issue, only me
+ <teythoon> yes, i do
+ <braunr> yes, i see
+ <teythoon> however, i'm also using --sync 30 on my fs
+ <braunr> ok so you couldn't reproduce that particular issue
+ <braunr> hum
+ <braunr> try --sync=30
+ <teythoon> showtrans /media/scratch
+ <teythoon> /hurd/ext2fs --sync=30 /dev/sd1s1
+ <teythoon> works fine
+ <braunr> now that's weird :)
+ <teythoon> then again, previously there was another bug
+ <braunr> but then the patches i've tested are not the complete series you
+ sent
+ <teythoon> in the dir lookup function, if a passive translator is started
+ <teythoon> say, if i first access /proc/foo, /proc/foo would be recorded,
+ not /proc
+ <teythoon> i fixed that yesterday
+ <braunr> ok
+ <teythoon> maybe it was b/c of that
+ <braunr> but hm
+ <braunr> why would /proc be recorded ?
+ <teythoon> now ?
+ <braunr> i mean, /proc should be recorded at /, and /foo at /proc
+ <braunr> right ?
+ <teythoon> yes
+ <braunr> and that wasn't the case ?
+ <teythoon> but what happened was that proc/foo was recorded as a child
+ translator for /
+ <braunr> ohh
+ <teythoon> yes
+ <braunr> i see
+ <braunr> well, i'm not sure it's that bug, since the translator involved
+ was on /home
+ <teythoon> same problem
+ <teythoon> it's unlikely that the translator was started b/c of a /home
+ lookup
+ <teythoon> much more likely that the first lookup is /home/someone
+ <braunr> yes
+ <braunr> but mtab correctly reported /home without --sync, and not when the
+ option was present
+ <braunr> and that part doesn't quite make sense to me
+ <teythoon> how did you trigger the startup
+ <teythoon> ?
+ <braunr> ssh i believe
+ <teythoon> hm
+ <teythoon> anyways, i could not reproduce this issue
+ <braunr> do you have packages somewhere i can test ?
+ <teythoon> yes
+ <braunr> oh and btw
+ <teythoon> http://darnassus.sceen.net/~teythoon/hurd-ci/
+ <braunr> something you could do to deal with umount -a
+ <braunr> but i guess that's what you did already
+ <braunr> is to only shut the active translator down
+ <teythoon>
+ http://git.sceen.net/hurd/hurd.git/commitdiff/0033d20449b3bb558f2ea470983018db39b572aa
+ <teythoon> yeah, i thought about that
+ <teythoon> but i believe that is not the right hting to do
+ <braunr> yes i know but i'm not sure that's the right approach
+ <braunr> hm :)
+ <teythoon> b/c if on linux you do umount /foo && ls /foo, foo will be empty
+ <braunr> yours is probably more posix-friendly
+ <teythoon> if the passive translator lookup is left, /foo will be restarted
+ <braunr> ok
+ <teythoon> s/lookup/record/
+ <braunr> that's one reason i'm not very fond of passive translators tbh
+ <teythoon> yep
+ <braunr> i'd reserve them as a user-oriented hurd-specific feature
+ <braunr> anything that must behave as mount/umount expects has to be active
+ anyway
+ <braunr> ok let's give a quick shot at your packages :)
+
+ <braunr> teythoon: works fine :)
+ <braunr> mtab still reports console entries though
+ <braunr> is tha texpected ?
+ <teythoon> braunr: kind of
+ <teythoon> braunr: /bin/console is a netfs-based translator, probably for
+ multiplexing, dunno exactly
+ <braunr> i see
+
+
+### IRC, freenode, #hurd, 2014-01-14
+
+ <youpi> teythoon: passive translators do work fine in mtab now, thanks :)
+ <braunr> indeed :)
+
+
+### IRC, freenode, #hurd, 2014-02-11
+
+ <antrik> another topic: what's the rationale again behind umount removing
+ passive translators?...
+ <teythoon> antrik: umount is for compatibility with unixoid systems
+ <teythoon> consider umount /foo; ls /foo
+ <teythoon> if umount would leave the passive translator record on /foo,
+ /foo would be started again
+ <antrik> but mount never creates passive translators, right?
+ <antrik> so why would umount remove them? they are none of its business...
+ <teythoon> sure, you can see it this way
+ <teythoon> still, i like the way it is now, hence i implemented it this way
+ ;)
+ <youpi> teythoon: but then umount -a unmounts all passive translators
+ <youpi> include ~joe/http:/
+ <youpi> s/include/including/
+ <youpi> I tend to agree with antrik
+ <teythoon> i won't oppose a change of course
+ <teythoon> and yes, we have seen problems b/c of that. otoh those can be
+ fixed (and they are, i just sent a patch fixing that)
+ <youpi> teythoon: well, it's not only about http:, joe user may want to
+ mount its own iso image, or whatever
+ <teythoon> thats true
+ <teythoon> no
+ <teythoon> it's not
+ <teythoon> /proc/mounts does not contain translators bound to nodes that do
+ not belong to root
+ <teythoon> but sure, we can change umount
+ <braunr> i agree
+ <braunr> active translators can be viewed as unix mounts
+ <braunr> passive translators are an entirely hurdish feature
+ <braunr> but then, servers such as pflocal and pfinet shouldn't probably
+ not be passive translators
+ <antrik> braunr: shouldn't not? what are you trying to say? :-)
+ <braunr> woops
+ <braunr> i'm not trying to make this unconfusingly clearer
+ <braunr> :p
+ <braunr> pflocal and pfinet should probably be active translators
+ <antrik> why?
+ <braunr> hum wait
+ <braunr> i had a reason weeks ago
+ <braunr> but now it looks the opposite is better actually :p
+ <braunr> so that they don't appear in mounts
+ <braunr> but aiui, there is another property that is tested to make
+ translators appear in mounts
+ <antrik> hm... I know this question has been discussed when first talking
+ about an mtab translator years ago... but don't remember whether there
+ was any conclusion
+ <antrik> I think one of the ideas was that translators would opt in for
+ being considered as mounts...
+ <braunr> it makes sense to only have file systems in mounts anyway
+ <antrik> instead of going by the translator type, another option might be
+ ignoring anything that is backed by a passive translator?...
+ <antrik> or have a startup option (perhaps with some "smart" defaults) to
+ request a translator to manifest as a mount or not
+ <antrik> so many ideas... ;-)
+
+
+## coreutils' `df`
+
+### IRC, freenode, #hurd, 2014-01-24
+
+ <braunr> gnu_srs: "df: Warning: cannot read table of mounted file systems:
+ No such file or directory"
+ <braunr> you should be able to fix that easily
+
+
+### IRC, OFTC, #debian-hurd, 2014-02-03
+
+ <pere> /run/mtab also seem to be missing. df do not work.
+ <teythoon> that's a libc bug
+
+
+### IRC, OFTC, #debian-hurd, 2014-02-05
+
+ <gg0> i had to ln -s /proc/mounts /var/run/mtab to make df work, what's the
+ proper fix?
+ <gg0> (here sysvinit+openrc)
+ <youpi> gg0: the proper fix for df is to fix the coreutils build
+
+ <pere> I checked the mtab problem, and /etc/hurd/runsystem.gnu via
+ /etc/hurd/rc fixes the symlink, while runsystem.sysv do not. I suspect
+ /etc/init.d/checkroot.sh should fix the symlink too.
+ <youpi> well, atm df looks at /var/run/mtab instead of /etc/mtab only
+ because it hasn't been rebuilt against a recent glibc, that's all
+ <youpi> but we can brownpaperbag fix it, yes
+ <pere> right. so perhaps that is the bug to fix?
+ <youpi> yes, it is
+ <youpi> it depends on coreutils actually building
+ <teythoon> youpi: i thought the proper way to fix the /var/run/mtab issue
+ is to patch the libc ?
+ <youpi> it is
+ <teythoon> the libc defines some macro, on linux it expands to /etc/mtab,
+ on hurd to /var/run/mtab
+ <youpi> but you need to rebuild coreutils to get a fixed df
+ <teythoon> ok, right
+ <pere> should it be /var/run/mtab or /etc/mtab on hurd? the former seem
+ more correct, but /run/mtab give more sense given that it should be
+ available also before /var/ is mounted.
+ <youpi> to be honest, I don't really care
+ <youpi> and I thus tend to agree on sticking with what linux does
+ <youpi> to avoid issues
+ <youpi> as in: keep debian working mostly the same on all kernels, to avoid
+ issue
+ <youpi> s
+ <pere> well, linux really should move that file away from /etc/ too. :)
+ <youpi> pere: ok, but let's move at the same time
+ <youpi> rather than hitting bugs ourselves
+ <pere> perhaps df should use /proc/mount instead, and get rid of the
+ problem completely...
+ <youpi> that can be a way, too
+
+ <pere> I believe <URL: http://bugs.debian.org/737759 > is a good fix for
+ the mtab problem.
+
+ <rleigh> WRT /etc/mtab the main reason for keeping it is solely for
+ compatibility; there's no reason not to use /proc/mounts directly (or
+ /run/mtab if we want a kernel-agnostic location). Whether it's worth
+ doing something like that is debatable.
+ <rleigh> The main issue with doing stuff like this nowadays is that you get
+ shouted at by all the systemd people for making changes...
+
+
+## Memory Leak in `translator_ihash_cleanup`
+
+### IRC, freenode, #hurd, 2013-10-04
+
+ <braunr> teythoon: isn't there a leak in translator_ihash_cleanup ?
+ <teythoon> braunr: looks like, yes
+ <teythoon> braunr: I probably forgot to add the free (element->name) when I
+ added the name field
+ <braunr> teythoon: ok
+ <braunr> teythoon: i let you fix that :p
+ <teythoon> braunr: sure ;)