Re: reiser4 and bonnie problems

[Alex Zarochentsev <zam@namesys.com>]

On Tue, Apr 20, 2004 at 05:37:39PM +0400, Nikita Danilov wrote:
> Paul Wagland writes:
>  > 
>  > On Apr 20, 2004, at 9:51, Nikita Danilov wrote:
>  > 
>  > > Paul Wagland writes:
>  > >> Bonnie: drastic I/O error (write(2)): No space left on device
>  > >
>  > > Err.. this is completely different from what we had previously: "No
>  > > space left on device" is understandable where not reasonable. What is
>  > > completely mysterious is "No such file or directory" error that you
>  > > reported before.
>  > 
>  > Yes, last night I could not get that "No such file or directory" error 
>  > to appear. I will try to reproduce that particular error again later 
>  > tonight. However, this other problem happens at exactly the same time, 
>  > and is an error in the reiser4.
>  > 
>  > Just to summarise everything that is written below, this is what bonnie 
>  > is doing:
>  > 1. write 3.5 GB onto a 4GB partition. This works
>  > 2. delete 3.5 GB from a 4GB partition. This works.
> 
> Disk blocks freed during transaction are not actually freed until
> transaction commits.
> 
>  > 3. I check using df that the disk space is free. That works.
> 
> But that "delayed freeing" confused users (they did cp, rm, but df has
> still showed that space is used), so that statfs(2) (system call used by
> df) was modified to take these delayed blocks into account and pretend
> that they are free.
> 
>  > 4. write 3.5GB onto a 4GB partition. This fails.
> 
> Try to repeat this with sync before step 4.
> 
>  > 
>  > At the time of failure, according to df there is stiff 3.5 GB
>  > free. So, I say that reiser4 has a problem.
> 
> df lies.

reiser4_statfs() was changed to report deleted blocks as free space immediately
after rm(1).  

It was done because reiser4_write() should trigger fs commit and recover free
space.   If commit does not happen, it is a reiser4 bug.

>  > Paul
> 
> Nikita.

-- 
Alex.