From 3bf27c93ac4de57623809b71517116d51465f0e1 Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Sat, 17 Mar 2012 12:31:07 +0100 Subject: IRC bits. --- hurd/translator/tmpfs/discussion.mdwn | 93 +++++++++++++++++++++++++++++++++++ 1 file changed, 93 insertions(+) (limited to 'hurd/translator/tmpfs') diff --git a/hurd/translator/tmpfs/discussion.mdwn b/hurd/translator/tmpfs/discussion.mdwn index 0409f046..1d441c7d 100644 --- a/hurd/translator/tmpfs/discussion.mdwn +++ b/hurd/translator/tmpfs/discussion.mdwn @@ -283,3 +283,96 @@ License|/fdl]]."]]"""]] what kind of log do you mean? vmstat 1 I mean ah... + + +## IRC, freenode, #hurd, 2012-02-01 + + I run fsx with this command: fsx -N3000 foo/bar -S4 + -l$((1024*1024*8)). And after 70 commands it breaks. + The strangeness is at address 0xc000 there is text, which was + printed in fsx with vfprintf + I've lost log. Wait a bit, while I generate new + mcsim, what's fsx / where can I find it ? + fsx is filesystem exersiser + http://codemonkey.org.uk/projects/fsx/ + ok thanks + i use it to test tmpfs + here is fsx that compiles on linux: http://paste.debian.net/154390/ + and Makefile for it: http://paste.debian.net/154392/ + mcsim, hmm, I get a failure with ext2fs too, is it expected? + yes + i'll show you logs with tmpfs. They slightly differ + here: http://paste.debian.net/154399/ + pre last operation is truncate + and last is read + during pre-last (or last) starting from address 0xa000, every + 0x1000 bytes appears text + skipping zero size read + skipping zero size read + truncating to largest ever: 0x705f4b + signal 2 + testcalls = 38 + this text is printed by fsx, by function prt + I've mistaken: this text appears even from every beginning + I know that this text appears exactly at this moment, because I + added check of the whole file after every step. And this error appeared + only after last truncation. + I think that the problem is in defpager (I'm fixing it), but I + don't understand where defpager could get this text + wow I get java code and debconf templates + So, my question is: is it possible for defpager to get somehow this + text? + possibly recycled, non-zeroed pages? + hmmm... probably you're right + 0x1000 bytes is consistent with the page size + Should I clean these pages in tmpfs? + or in defpager? + What is proper way? + mcsim, I'd say defpager should do it, to avoid leaking + information, I'm not sure though. + maybe tmpfs should also not assume the pages have been blanked + out. + if i do it in both, it could have big influence on performance. + i'll do it only in defpager so far. + jkoenig_: Thank you a lot + mcsim, no problem. + + +## IRC, freenode, #hurd, 2012-02-08 + + mcsim: You pushed another branch with cleaned-up patches? + yes. + mcsim: Anyway, any data from your report that we could be + interested in? (Though it's not in English.) + It's completely in ukrainian an and mostly describes some aspects + of hurd's work. + mcsim: OK. So you ran out of time to do the benchmarking, + etc.? + Comparing tmpfs to ext2fs with RAM backend, etc., I mean. + tschwinge: I made benchmarking and it turned out that tmpfs up to 6 + times faster than ext2fs + tschwinge: is it possible to have a review of work, I've already + done, even if parallel writing doesn't work? + mcsim: Do you need this for university or just a general review + for inclusion in the Git master branch? + general review + Will need to find someone who feels competent to do that... + the branch that should be checked is tmpfs-final + cool, i guess you tested also special types of files like + sockets and pipes? (they are used in eg /run, /var/run or similar) + Oh. I accidentally created this branch. It is my private + branch. I'll delete it now and merge everything to mplaneta/tmpfs/master + pinotree: Completely forgot about them :( I'll do it by all means + mcsim: no worries :) + tschwinge: Ready. The right branch is mplaneta/tmpfs/master + + +## IRC, freenode, #hurd, 2012-03-07 + + did you test it with sockets and pipes? + pinotree: pipes work and sockets seems to work too (I've created + new pfinet device for them and pinged it). + try with simple C apps + Anyway all these are just translators, so there shouldn't be any + problems. + pinotree: works -- cgit v1.2.3