Re: ReiserFS causes CPU high usage?!

2003-02-28 Thread Toby Dickenson
On Friday 28 February 2003 12:11 pm, Voicu Liviu wrote:

 Already using this :-)
 Any way, the system works great but if I change the nice value of some
 process then the CPU almost becomes slave of this process.

If that means the compile finishes faster (and you havent said whether or not 
it does) then isnt using more of the cpu a good thing?





[reiserfs-list] integrity question

2002-05-25 Thread Toby Dickenson

I am developing a storage layer for the ZODB object database, which is 
designed to play to reiserfs strengths. 

http://sourceforge.net/projects/dirstorage

I have a question about how much fsyncing is necessary to avoid losing files 
on power loss, when moving them between directories.

Consider this sequence

1. write to A/B/somefileX and fsync it
2. mkdir A/C
3. rename A/B/somefile to A/C/somefile
4. rmdir A/B
5. power loss

I would like to guarantee that, after journal replay, 'somefile' is in either 
of those two directories (or both). Am I correct to think that I dont need 
any other syncs in there?

(A second question; is there any documentation that I could have used to 
answer the first question myself?)



Re: [reiserfs-list] fsync() Performance Issue

2002-04-29 Thread Toby Dickenson

On Mon, 29 Apr 2002 18:20:18 +0200, Russell Coker
[EMAIL PROTECTED] wrote:

On Fri, 26 Apr 2002 22:28, [EMAIL PROTECTED] wrote:

It's interesting to note your email address and what it implies...

  I'm wondering if anyone out there may have some suggestions on how
 to improve the performance of a system employing fsync(). I have to be able
 to guaranty that every write to my fileserver is on disk when the client
 has passed it to the server. Therefore, I have disabled write cache on the
 disk and issue an fsync() per file. I'm running 2.4.19-pre7, reiserfs
 3.6.25, without additional patches. I have seen some discussions out here
 about various other speed-up patches and am wondering if I need to add
 these to 2.4.19-pre7? And what they are and where can I obtain said
 patches? Also, I'm wondering if there is another solution to syncing the
 data that is faster than fsync(). Testing, thusfar, has shown a large
 disparity between running with and without sync.Another idea is to explore
 another filesystem, but I'm not exactly excited by the other journaling
 filesystems out there at this time. All ideas will be greatly appreciated.

These issues have been discussed a few times, but not with any results as 
exciting as you might hope for.  One which was mentioned was using 
fdatasync() instead of fsync().

One thing that has occurred to me (which has not been previously discussed as 
far as I recall) is the possibility for using sync() instead of fsync() if 
you can accumulate a number of files (and therefore replace many fsync()'s 
with one sync() ).

I can see

write to file A
write to file B
write to file C
sync

might be faster than

write to file A
fsync A
write to file B
fsync B
write to file C
fsync C

but is it possible for it to be faster than

write to file A
write to file B
write to file C
fsync A
fsync B
fsync C

?



Toby Dickenson
[EMAIL PROTECTED]



Re: [reiserfs-list] ReiserFS data corruption in very simple configuration

2001-10-03 Thread Toby Dickenson

Of course. If you want data to hit the disk, you have to use fsync. This
does work with reiserfs and will ensure that the data hits the disk. If
you don't do this then bad things might happen.

This is probably a naive question, but this thread has already proved
me wrong on one naive assumption.

If the sequence is:
1. append some data to file A
2. fsync(A)
3. append some further data to A
4. some writes to other files
5. power loss

Is it guaranteed that all the data written in step 1 will still be
intact?

The potential problem I can see is that some data from step 1 may have
been written in a tail, the tail moves during step 3, and then the
original tail is overwritten before the new tail (including data from
before the fsync) is safely on disk.

Thanks for your help,


Toby Dickenson
[EMAIL PROTECTED]