From: Howie <how...@gm...> - 2005-04-21 11:08:18
|
>I'm having the same problem with a small file system I'm working on. >The lost in performance for file writing is about 30% and i think it's >caused for the 4K blocks.... I 'm also have this problem . This is the performance testing which use "Bonnie tools" =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D -------Sequential Output---------------------------=20 ----Sequential Input------- -- Random ---Per Char----- ----Block------ --Rewrite------- -----Per Char- --Block----- ---Seeks-- Machine MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU /sec=20 local 100 28045 99.7 195131 101.0 321515 100.5 38494 101.1 1217829 95.1 108324.8 fuse1 100 24253 66.6 85965 21.0 65853 18.0 32531 82.6 =20 148139 14.5 15607.1 fuse2 100 29626 72.3 94936 22.3 123942 29.0 43572 99.6=20 1481160 100 39950.1 ---------------------------------------------------------------------------= -------------------------------------------------------- fuse1 without large_read ,fuse2 use large_read kernel_cache when we use large_read the read performance is as good as local operation. But write will loss some performance. Is it possible have large_write option ,the same as large_read. howie |
From: Leandro F. <leo...@gm...> - 2005-04-21 11:30:42
|
As far as I understand... The option can't be implemented in the kernel side and it's left to us if we want to implement it in userspace .... I did the necessary arrangements in my file system to have the writing cache but it's kind of messy and i took a simplistic solution when the writes are not in sequential order (although, i havent tried it yet) ... However, if someone wants to write a clean way to do it i'll be willing to help.... Leandro On 4/21/05, Howie <how...@gm...> wrote: > >I'm having the same problem with a small file system I'm working on. > >The lost in performance for file writing is about 30% and i think it's > >caused for the 4K blocks.... >=20 > I 'm also have this problem . > This is the performance testing which use "Bonnie tools" > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > -------Sequential Output--------------------------- > ----Sequential Input------- -- Random > ---Per Char----- ----Block------ --Rewrite------- > -----Per Char- --Block----- ---Seeks-- > Machine MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU /sec > local 100 28045 99.7 195131 101.0 321515 100.5 38494 101.1 > 1217829 95.1 108324.8 > fuse1 100 24253 66.6 85965 21.0 65853 18.0 32531 82.6 > 148139 14.5 15607.1 > fuse2 100 29626 72.3 94936 22.3 123942 29.0 43572 99.6 > 1481160 100 39950.1 > -------------------------------------------------------------------------= ---------------------------------------------------------- >=20 > fuse1 without large_read ,fuse2 use large_read kernel_cache > when we use large_read the read performance is as good as local operation= . > But write will loss some performance. >=20 > Is it possible have large_write option ,the same as large_read. >=20 > howie > |
From: Howie <how...@gm...> - 2005-04-21 16:03:27
|
In the early discuss,miklos say we can make a buffer when do open,and stick it on fi->fh When buffer is full, sent it out . Does this buffer means some kind of write cache? and some kind of delay-wri= te ? But how can we predict we will still have write operation. When will we sent the buffer out ,if the buffer is not full . ...@@ It is really a big troble to me. 2005/4/21, Leandro Franco <leo...@gm...>: > As far as I understand... >=20 > The option can't be implemented in the kernel side and it's left to us > if we want to implement it in userspace .... >=20 > I did the necessary arrangements in my file system to have the writing > cache but it's kind of messy and i took a simplistic solution when the > writes are not in sequential order (although, i havent tried it yet) > ... >=20 > However, if someone wants to write a clean way to do it i'll be > willing to help.... >=20 >=20 > Leandro >=20 > On 4/21/05, Howie <how...@gm...> wrote: > > >I'm having the same problem with a small file system I'm working on. > > >The lost in performance for file writing is about 30% and i think it's > > >caused for the 4K blocks.... > > > > I 'm also have this problem . > > This is the performance testing which use "Bonnie tools" > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > -------Sequential Output--------------------------- > > ----Sequential Input------- -- Random > > ---Per Char----- ----Block------ --Rewrite------- > > -----Per Char- --Block----- ---Seeks-- > > Machine MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU /sec > > local 100 28045 99.7 195131 101.0 321515 100.5 38494 101.1 > > 1217829 95.1 108324.8 > > fuse1 100 24253 66.6 85965 21.0 65853 18.0 32531 82.6 > > 148139 14.5 15607.1 > > fuse2 100 29626 72.3 94936 22.3 123942 29.0 43572 99.6 > > 1481160 100 39950.1 > > -----------------------------------------------------------------------= ------------------------------------------------------------ > > > > fuse1 without large_read ,fuse2 use large_read kernel_cache > > when we use large_read the read performance is as good as local operati= on. > > But write will loss some performance. > > > > Is it possible have large_write option ,the same as large_read. > > > > howie > > > |
From: Miklos S. <mi...@sz...> - 2005-04-21 17:21:37
|
> In the early discuss,miklos say we can make a buffer when do open,and > stick it on fi->fh > When buffer is full, sent it out . > Does this buffer means some kind of write cache? and some kind of delay-write ? You can implement it as a cache: writes to regions already in the cache overwrite the old data, and reads will check if data is in the cache. The other way to implement it is a simple linear buffer. That means, that whenever there's a write which is not to the end of the buffer, or if there's a read, the buffer is first flushed and then the original operation can continue. > But how can we predict we will still have write operation. > When will we sent the buffer out ,if the buffer is not full . ...@@ > It is really a big troble to me. You can have a timeout for the buffer. Probably the simplest is to have a separate thread which periodically flushes all buffers, which have not been written to recently. Miklos |