From c3319f15a7b5343e38f2143cd5bdfef88ad5638b Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Wed, 19 Dec 2007 23:34:55 +0100 Subject: hurd/translator/tmpfs/notes_various: New. Assembled from IRC logs. --- hurd/translator/tmpfs/notes_various.mdwn | 201 +++++++++++++++++++++++++++++++ 1 file changed, 201 insertions(+) create mode 100644 hurd/translator/tmpfs/notes_various.mdwn (limited to 'hurd') diff --git a/hurd/translator/tmpfs/notes_various.mdwn b/hurd/translator/tmpfs/notes_various.mdwn new file mode 100644 index 00000000..e323a890 --- /dev/null +++ b/hurd/translator/tmpfs/notes_various.mdwn @@ -0,0 +1,201 @@ + hde: what's the status on tmpfs? + Broke + k0ro traced the errors like the assert show above to a pager problem. + See the pager cannot handle request from multiple ports and tmpfs sends + request using two differ ports, so to fix it the pager needs to be hacked + to support multiple requests. + You can enable debugging in the pager by changing a line from dprintf + to ddprintf I can tell you how if you want. + and changing tmpfs to use a single port isn't possible?... + antrik, I am not sure. + IIRC k0ro was saying it cannot be changed and I cannot recall his + reasons why. + antrik: Doing it the quick&dirty way, I'd just use an N-ary + tree for representing the directory structure and mmap one new page (or + more) for each file. + sdschulze, What are you talking about? + hde: about how I would implement tmpfs + O + sdschulze: you don't need to reimplement it, just fix it :) + azeem: Well, it seems a bit more difficult than I considered. + I had assumed it was implemented the way I described. + O and the assert above gets triggered if you don't have a + default-pager setup on /servers/default-pager + the dir.c:62 assert that is. + hde: you sure? I think I have one + I am almost sure. + mbanck@beethoven:~$ showtrans /servers/default-pager + /hurd/proxy-defpager + isn't that enough? + It is suppose to be. + Try it as root + I was experiecing alot of bugs as a normal user, but according to + marcus it is suppose to work as root, but I was getting alot of hangs. + hde: same issue, sudo doesn't work + sucky, well then there are alot of bugs. =) + eh, no + I still get the dir.c assert + me too + Without it, I already get an error message trying to set tmpfs + as an active translator. + +--- + + I think I found the colprit. + default_pager_object_set_size --> This is were tmpfs is hanging. + mmm Hangs on the message to the default-pager. + +--- + + Well it looks like tmpfs is sending a message to the default-pager, + the default-pager then receives the message and, checks the seqno. I + checked the mig gen code and noticed that the seqno is the reply port, it + this does not check out then the default pager is put into a what it + seems infinte condition_wait hoping to get the correct seqno. + Now I am figuring out how to fix it, and debugging some more. + +--- + + hde: Still working on tmpfs? + Yea + Did you fix a lot already? + No, just trying to narrow down the reason why we cannot write file + greater then 4.5K. + ahh + What did you figure out so far? + I used the quick marcus fix for the reading assert. + reading assert? + Yea you know ls asserted. + oh? :) + Because, the offsets changed in sturct dirent in libc. + They added 64 bit checks. + So marcus suggested a while ago on bug-hurd to just add some padding + arrays to the struct tmpfs_dirent. + And low and behold it works. + Oh, that fix. + Yup + marco_g, I have figured out that tmpfs sends a message to the + default-pager, the default-pager does receive the message, but then + checks the seqno(The reply port) and if it is not the same as the + default-pagers structure->seqno then she waits hoping to get the correct + one. Unfortantly it puts the pager into a infinite lock and never come + out of it. + hde: That sucks... + But at least you know what the problem is. + marco_g, Yea, now I am figuring out how to fix it. + Which requires more debugging lol. + There is also another bug, default_pager_object_set_size in + mach-defpager does never return when called and makes tmpfs hang. I + will have a closer look at this later this week. + +--- + + Cool, now that I have two pagers running, hopefully I will have less + system crashes. + running more than one pager sounds like trouble to me, but maybe + hde means something different than I think + Well the other pager is only for tmpfs to use. + So I can debug the pager without messing with the entire system. + marcus, I am trying ti figure out why diskfs_object_set_size waits + forever. This way when the pager becomes locked forever I can turn it + off and restart it. When I was doing this with only one mach-defpager + running the system would crash. + hde: how were you able to start two default pagers?? + Well you most likely will not think my way of doing it was correct, + and I am also not sure if it is lol. I made my hacked version not stop + working if one is alreay started. + +--- + + See, the default-pager has a function called + default_pager_object_set_size this sets the size for a memory object, + well it checks the seqno for each object if it is wrong it goes into a + condition_wait, and waits for another thread to give it a correct seqno, + well this never happens. + Thus, you get a hung tmpfs and default-pager. + pager_memcpy (pager=0x0, memobj=33, offset=4096, other=0x20740, + size=0x129df54, prot=3) at pager-memcpy.c:43 + bddebian, See the problem? + pager=0x0? + Yup + Now wtf is the deal, I must debug. + -- Function: struct pager * diskfs_get_filemap_pager_struct + (struct node *NP) + Return a `struct pager *' that refers to the pager returned by + diskfs_get_filemap for locked node NP, suitable for use as an + argument to `pager_memcpy'. + That is failing. + If it is not one thing it is another. + All of Mach fails ;-) + It is alot of work to make a test program that uses libdiskfs. + +--- + + to run tmpfs as a regular user, /servers/default-pager must be + executable by that user. by default it seems to be set to read/write. + $ sudo chmod ugo+x /servers/default-pager + you can see the O_EXEC in tmpfs.c + maybe this is just a debian packaging problem + it's probably a fix to native-install i'd guess + +--- + + tmpfs is failing on default_pager_object_create with -308, which + means server died + i'm running it as a regular user, so it gets it's pager from + /servers/default-pager + and showtrans /servers/default-pager shows /hurd/proxy-defpager + so i'm guessing that's the server that died + +--- + + this is about /hurd/tmpfs + a filesystem in memory + such that each file is it's own memory object + what does that mean exactly? it differs from a "ramdisk"? + instead of the whole fs being a memory object + it only allocates memory as needed? + each file is it's own + andar: yeah + it's not ext2 or anything + yea + it's tmpfs :-) + first off, echo "this" > that + fails + with a hang + on default_pager_object_create + so writing to the memory object fails + well, it's on the create + ah + and it returns -308 + which is server died + in mig-speak + but if i run it as root + things behave differently + it gets passed the create + but then i don't know what + i want to make it work for the regular user + it doesn't work as root either, it hangs elsewhere + but it at least creates the memory object + that's the braindump + but it's great for symlinks! + do you know if it creates it? + i could do stowfs in it + +--- + + bing: k0ro (I think) analized the tmpfs problem some two years ago + or so, remember?... + it turns out that it broke due to some change in other stuff + (glibc I think) + problem was something like getting RPCs to same port from two + different sources or so + and the fix to that is non-trivial + I don't remember in what situations it broke exactly, maybe when + writing larger files? + antrik: yeah i never understood the explanation + antrik: right now it doesn't write any files + the change in glibc was to struct dirent + seems something more broke in the meantime :-( + ah, right... but I the main problem was some other change + (or maybe it never really worked, not sure anymore) -- cgit v1.2.3