[[!meta copyright="Copyright © 2005, 2006, 2007, 2008, 2009, 2011 Free Software Foundation, Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is included in the section entitled [[GNU Free Documentation License|/fdl]]."]]"""]] [[!tag open_issue_hurd]] 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) --- IRC, freenode, #hurd, 2011-10-11: There is no patch for "tmpfs crashes on filling an empty file". For second bug there is Zheng Da's patch, but it wasn't applied (at least I didn't found).