diff options
Diffstat (limited to 'hurd/translator/mtab')
| -rw-r--r-- | hurd/translator/mtab/discussion.mdwn | 552 |
1 files changed, 550 insertions, 2 deletions
diff --git a/hurd/translator/mtab/discussion.mdwn b/hurd/translator/mtab/discussion.mdwn index 961711f3..bac32906 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]] @@ -2496,6 +2502,548 @@ Fixed in 2013-10-05 procfs commit c87688a05a8b49479ee10127470cc60acebead4a? <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 |