diff options
Diffstat (limited to 'hurd/translator/mtab/discussion.mdwn')
| -rw-r--r-- | hurd/translator/mtab/discussion.mdwn | 958 |
1 files changed, 939 insertions, 19 deletions
diff --git a/hurd/translator/mtab/discussion.mdwn b/hurd/translator/mtab/discussion.mdwn index 0734e1e6..d663d4c5 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,6 @@ 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 ## IRC, freenode, #hurd, 2013-09-06 @@ -2103,7 +2094,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 +2270,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 ;) |