Re: secure delete?
Is there a way to securely delete a file or directory in ReiserFS or Reiser4? By securely delete I mean the kind of thing one of the PGP tools tries to do (i.e. overwrite the disk area with random bits several times). Of course this only works if the information is not moved around physically a lot (i.e. at all). Could secure delete work? Peter srm will do the trick (securerm).. Cami
Re: [PATCH] metas in reiserfs v4 snapshot 2004.03.26
Good point, search engines as evidence. The problem is you're only looking at distributions, which are going to be highly similar and you're completely missing end users. So let us take this to a full search engine and see what turns up... Hmm, roughly a million hits, let us look at a few samples: http://www.metas.ch/ http://vancouver-webpages.com/META/mk-metas.html http://www.metas.com.br/ http://metas.enfermeria21.com/ http://www.metas.com.mx/ Okay, out of one million hits, we randomly look at ten, and half feature metas in the URL somewhere. Going the other direction, Google indexes roughly 4 billion pages. If we guess the above search was representative, roughly 500,000 pages will include metas somewhere in the URL, possibly only as a hostname, but somewhere. So we've managed to collect 1 out of every 10,000 pages that Google indexes. Though we don't have a direct proof, I hope I've come close enough to scare you. Quite true.. ..metas or .metas would be the better choice.. Regards, Cami
Re: reiserfs v3 patches updated
What i then tried on machine1 was remounting it noatime,nodiratime and what was wierd was that the iowait stayed exactly the same, no indication of dropping at all.. Does the kernel patches change any of the default mount options at all? If i put the stock 2.6.5 kernel back on without the patch applied and mount it back as noatime,nodiratime, the iowait drops back to its normal 1%.. Do you have any numbers for the amount of mail delivered per second on each box? Currently, each machine is doing about 10 mails per second. Puring peak hours this figure can increase to the 20's and 30's and about 1500 concurrent connections each (at around 20mbit/s of incoming mail).. I've got an idea that should help lower the io wait percentage as well, trying a few things here. I'll be looking forward to that.. Cami
Re: reiserfs v3 patches updated
The majority of the rest of the machines iowait hover around the 1% mark.. CPU time tends to be about the same, just the iowait is much much higher.. Very interesting. data=ordered makes fsync more expensive, since it ends up syncing more then just the buffers for that one file. Could you please try removing data=ordered from machine1? Ok.. after leaving it for a few minutes.. I'm a little slow today. data=ordered is the default with these patches. You need to mount -o data=writeback. data=writeback yields pretty much the same iowait results.. (machine 1+2 are around 5%-8% whereas machine 3-8 are at around 0.8%) Cami
Re: reiserfs v3 patches updated
I'm a little slow today. data=ordered is the default with these patches. You need to mount -o data=writeback. data=writeback yields pretty much the same iowait results.. (machine 1+2 are around 5%-8% whereas machine 3-8 are at around 0.8%) This is so much faster I'm worried the io isn't actually getting done. In the mail server benchmark I use (synctest -n 1 -t 50 -f -F), the time went from 2m15s to 43s. The old 2m15s was still faster then I used to get with unpatched reiserfs. I'm posting this for the truly brave among you and a little review. I need to do more tests on it. The basic idea is to make sure we don't start writeback on the log buffers and metadata if someone is already doing it. Also, the reiserfs work queue is not kicked during transaction end if some other process is going to do the commit. This saves a lot of context switches. And just as i was about to head into bed ;) 23:26:25 up 5 min, 1 user, load average: 0.62, 0.36, 0.14 340 processes: 339 sleeping, 1 running, 0 zombie, 0 stopped CPU states: cpuusernice systemirq softirq iowaitidle total7.6%0.0% 30.8% 0.0% 1.2%0.4% 358.8% cpu001.7%0.0%6.6% 0.1% 1.1%0.1% 90.0% cpu012.1%0.0% 11.1% 0.0% 0.0%0.0% 86.7% cpu022.0%0.0%6.8% 0.0% 0.0%0.3% 90.6% cpu031.9%0.0%6.7% 0.0% 0.0%0.1% 91.1% 23:27:11 up 5 min, 1 user, load average: 0.40, 0.34, 0.14 343 processes: 342 sleeping, 1 running, 0 zombie, 0 stopped CPU states: cpuusernice systemirq softirq iowaitidle total6.8%0.0% 26.0% 0.0% 0.8%0.4% 364.8% cpu001.7%0.0%5.9% 0.1% 0.9%0.1% 91.0% cpu011.5%0.0%5.3% 0.0% 0.0%0.0% 93.1% cpu021.9%0.0%4.7% 0.0% 0.0%0.1% 93.1% cpu031.9%0.0%9.9% 0.0% 0.1%0.0% 87.9% 23:27:21 up 5 min, 1 user, load average: 0.63, 0.40, 0.16 343 processes: 342 sleeping, 1 running, 0 zombie, 0 stopped CPU states: cpuusernice systemirq softirq iowaitidle total8.0%0.0% 28.4% 0.0% 1.2%0.4% 360.8% cpu002.2%0.0%6.1% 0.1% 1.1%0.0% 90.2% cpu012.0%0.0% 10.4% 0.0% 0.1%0.3% 86.8% cpu021.7%0.0%6.4% 0.0% 0.0%0.1% 91.6% cpu031.7%0.0%5.7% 0.0% 0.0%0.1% 92.3% 23:27:32 up 6 min, 1 user, load average: 0.53, 0.38, 0.16 343 processes: 341 sleeping, 2 running, 0 zombie, 0 stopped CPU states: cpuusernice systemirq softirq iowaitidle total 10.0%0.0% 35.6% 0.0% 1.6%0.8% 350.8% cpu002.4%0.0%8.3% 0.1% 1.3%0.1% 87.4% cpu012.6%0.0% 11.8% 0.0% 0.1%0.1% 85.1% cpu022.4%0.0%7.8% 0.0% 0.1%0.1% 89.3% cpu032.4%0.0%8.0% 0.0% 0.0%0.3% 89.1% 23:27:37 up 6 min, 1 user, load average: 0.49, 0.38, 0.16 343 processes: 342 sleeping, 1 running, 0 zombie, 0 stopped CPU states: cpuusernice systemirq softirq iowaitidle total6.4%0.0% 26.4% 0.0% 0.4%0.0% 365.2% cpu001.7%0.0%5.9% 0.1% 0.5%0.0% 91.6% cpu011.5%0.0%9.5% 0.0% 0.0%0.0% 88.9% cpu021.7%0.0%5.5% 0.0% 0.0%0.1% 92.5% cpu031.7%0.0%5.7% 0.0% 0.1%0.1% 92.2% 23:27:47 up 6 min, 1 user, load average: 0.41, 0.36, 0.16 343 processes: 342 sleeping, 1 running, 0 zombie, 0 stopped CPU states: cpuusernice systemirq softirq iowaitidle total8.0%0.0% 29.2% 0.0% 1.2%0.4% 360.0% cpu002.0%0.0%9.7% 0.1% 0.9%0.1% 86.8% cpu012.2%0.0%5.9% 0.0% 0.0%0.1% 91.6% cpu021.7%0.0%7.4% 0.0% 0.1%0.0% 90.6% cpu032.4%0.0%6.1% 0.0% 0.0%0.3% 91.0% Hrmph! Its not going above 0.8% iowait.. it hangs around the 0.0% - 0.04% mark.. Looks good, thanks.. ;) Regards, Cami
Re: we got the DARPA grant to add views to Reiser4
Yeah! Details later. Congratulations! I'm too curious to wait, got any paper anywhere that covers/explains what views is? Cami
Re: Please /dev/null html-only mail rather than sending it out on this list
On Sun, Apr 18, 2004 at 11:58:08PM -0700, The Amazing Dragon wrote: Most servers get patches to fix security holes. SpamAssassin gets patches to spam holes. Both are annoying. Or get DSPAM that the users train and the SysAdmin can got fix security holes ;^) oh... actually i found out that bayesian rules for spamassiasin is also whole lot of security grief.. Huh? What specifically are you referring to here? and simply could be source of problem when someone does something simply stupid (not evil). Using SpamAssasin+custom rulesets (ask me if you want them) and then combined with Bayes, you'll eliminate close to 99% of the spam that hits the reiser mailing list.. Regards, Cami
Re: Reiserfs, highquality meds source, low rates
i am just not sure how to kill THIS messages which look so they dont look like spam, even to me upon first look. If you were using SpamAssasin, you wouldn't get these.. can someone get some medications that will cure those spammers (8 just not enough, rack on some more ammo, and dont be shy to call for airstrike) Ciao, baby! :) Solvency is maintained by means of a national debt, on the principle, ''If you will not lend me the money, how can I pay you? The narrative impulse is always with us we couldn't imagine ourselves through a day without it. Reiserfs, newest medications, low rates http://filiopietistic.rx-plus.net/?dcent unipod This country has come to feel the same when Congress is in session as when the baby gets hold of a hammer. If Jesus Christ be God and died for me, then no sacrifice can be too great for me to make for Him. Let your best be for your friend... Life does not require us to make good it asks only that we give our best at each level of experience. nice saying indeed ;)
--rebuild-tree
Hi All, Last night i done monthly maintence on all of my mailhosts and after doing a reiserfsck, it looks like i'll have to rebuild the tree on one of my mail clusters (the other 8 clusters were fine).. [mailhost01][/root]# df -h FilesystemSize Used Avail Use% Mounted on /dev/emcpowera1 152G 35G 117G 23% /var/spool/virtual Can anyone tell me roughly how dangerous this is and roughly how long something like this will take? The filesystem stores all the users mailboxes in maildir format so there are millions of files.. Any tips/comments would be appreciated.. Regards, Cami
