Re: [reiserfs-list] Status of reiserfs and ACLs?
Florin Andrei wrote: > - XFS is very fast when it comes to reading/writing to/from very large > files, especially when you need high sustained I/O rates, and more > especially under concurrent access and in multi-CPU environments (no > wonder it does that, because that's what it was designed for). Think of > large databases, or big multimedia applications. ReiserFS V4 will have some interesting approaches to speeding this up that should allow us to leapfrog XFS in this area. Unfortunately I can't describe them because the sponsor requires that we not talk about it until it works and ships. Since I am really quite happy to have it sponsored, and the sponsor has business reasons for it, I must respect this. V4 will also add ACLs. Hans
Re: [reiserfs-list] CPU useage of ReiserFS
Jens Benecke wrote: > > Hi, > > I just had a, er, 'lively' discussion with someone claiming ReiserFS is > crap because it hogs even the fastest CPU too much, and it uses 4x as much > processing power to do metadata operations, and in general is slower > because of the journal. My benchmarks don't reflect this, especially on > current hardware (ATA-66 and ATA-100 disks on VIA chipsets). > > While I agree that the journal does create an additional overhead, I'd like > to know if the CPU overhead is really that much. I've seen your benchmarks > on the web site but they don't say anything about CPU useage. > > -- > Jens Benecke > http://www.hitchhikers.de/ - Die kostenlose Mitfahrzentrale für ganz Europa > > > >Part 1.2Type: application/pgp-signature There is higher CPU overhead when using tails. I don't know about what happens without tails, never measured it. If you use large directories, ext2 dies under CPU overload. Hans
Re: [reiserfs-list] Initializing journal
Rasmus Bøg Hansen wrote: > > On 29 Jun 2001, [EMAIL PROTECTED] wrote: > > > How can we deactivate journal in reiserfs ? > > You can't deactivate the journal in a jounaling filesystem (not in > reiserfs anyway). If you do not want journaling, why do you not just use > ext2 then? > > Rasmus > > -- > -- [ Rasmus 'Møffe' Bøg Hansen ] -- > "Aren't you ashamed of yourself?" > "No, I have people to do that for me." > - [ moffe at amagerkollegiet dot dk ] -e there is a nolog option. Hans
Re: [reiserfs-list] Re: [reiserfs-dev] hash-collisions
Xuan Baldauf wrote: > * Tails-directories are slower by factor 3.7 than notails-directories. Is there any > way to optimize? My intuition says that tails-directories should be faster than > notails-directories, because due to the less data to be read, there should be less > disk accesses needed to do the same accesses. Why does this reasoning not apply? > It is because of the stupid place we put the stat data and directory entries, which was never what I desired but got into the code back in the days when I managed remotely, and we were going to fix it before shipping to Linus, and then code freeze for 2.4 hit. Plan A would put stat data and directory entries together, and would put them in the same packing locality as their corresponding file bodies. It will go into 2.4, along with plan B, and users will be able to choose which one matches their application. There actually are applications for which our current layout is optimal, but recursive directory traversals are not it. > > > > > > I'm not so sure it makes sense to include this hash in the standard > > kernel, because it's very special purpose - or we would end up with a > > hundred different hashes for different uses. I'm not so sure that's what > > we want? > > I'd like the idea of a hash module|plugin together with a 4-byte-hash-name or so > stored in every directory. Or more general, every directory has a directory_format > field in it's data structures, so alternative formats (like hashless stem > compression, etc.) can be implemented. Agreed. > > Xuân.
Re: [reiserfs-list] CPU useage of ReiserFS
Craig Sanders wrote: > performance, but XFS has had several years more debugging in real-world > conditions (on SGI's IRIX) So long as you are using XFS on IRIX, this counts for a lot. Hans
Re: [reiserfs-list] Re: [reiserfs-dev] hash-collisions
Ragnar Kjørstad wrote:
>
> > The hash is only 23 bits. From 7 up to 30. Low bits (0-6) are used to store
> > generation counter. Highest bit (31) is left 0, because offset in file in GNU
> > system is signed integer (off_t which is long int).
>
> Thanks for all your help.
>
> The new hash is now working well.
>
> The code is:
>
> /* Copyright Big Storage, 2000 */
> u32 maildir_hash (const char *msg, int len)
> {
> u32 num_part[3] = {0,0,0};
> int i;
> int j=0;
> for (i=0; i if (msg[i]>='0' && msg[i]<='9') {
> num_part[j]*=10;
> num_part[j]+=msg[i]-'0';
> } else {
> j++;
> if (j==3)
> break;
> }
> }
> if (num_part[0] && num_part[1] && num_part[2])
> return (num_part[0]<<7)+(num_part[1]<<5)+(num_part[2]<<5);
> else
> return r5_hash(msg, len);
> }
>
> And performance-numbers:
>
>untar find find
> reiserfs r5: 4m52.461s 10m42.421s 10m31.282s
> reiserfs tea: 5m00.709s 10m48.716s 10m36.089s
> reiserfs tea noatime: 4m45.495s5m26.378s5m33.648s
> reiserfs r5: 4m52.960s 10m37.554s 10m32.216s
> reiserfs r5 noatime: 4m50.794s5m17.570s5m24.448s
> reiserfs notail tea: 1m16.500s7m49.262s9m18.548s
> reiserfs notail tea noatime: 1m17.413s4m20.977s6m00.232s
> reiserfs notail r5:1m19.156s7m29.467s9m38.376s
> reiserfs notail r5 noatime:1m16.934s4m19.736s5m59.732s
> xfs: 9m41.229s0m55.330s1m06.169s
> xfs noatime: 9m34.167s0m51.635s1m03.481s
> reiserfs maildir: 3m01.894s4m19.049s4m46.440s
> reiserfs maildir noatime: 3m03.944s2m28.942s3m05.409s
> reiserfs notail maildir: 1m01.591s0m50.718s0m58.597s
> reiserfs notail maildir noatime: 1m01.045s0m40.927s0m48.239s
>
> Observations:
> * Creating the files on reiserfs is twice as fast as xfs
> * With "notail" it's even four times faster, 8 times faster than xfs!
> * XFS much faster then reiserfs for duing "find . -type f|xargs cat"
> Suprising to me, as this is a lot of small files, and exactly what
> reiserfs was built to do??
This requires plan A to fix. Plan A missed code freeze, and will go into v4.
> * Using noatime helps a lot, but reiserfs is still far behind.
> * Using the new hash, maildir-hash, improves untar performance a little
> bit, and find by a factor of 6!
>
> We will be testing this on a mailserver next to see what the impact will
> be on smtp and pop speeds.
>
> Regardless of those results, I believe that our findings show:
> * The choice of hash seems very important to filesystem-performance
> * On dedicated systems, performance can be improved a lot by
> creating a special hash for that task
> * XFS works much better than reiserfs without tweeks for this test.
> WHY?
>
> I'm not so sure it makes sense to include this hash in the standard
> kernel, because it's very special purpose - or we would end up with a
> hundred different hashes for different uses. I'm not so sure that's what
> we want?
>
> --
> Ragnar Kjorstad
> Big Storage
I have no problem with a hundred different hashes. Improve the commenting, deal with
the licensing
in some acceptable way, and we'll take the code
in 2.5.1.
Hans
