From mboxrd@z Thu Jan 1 00:00:00 1970 From: Alex Zarochentsev Subject: Re: reiser4 and bonnie problems Date: Tue, 20 Apr 2004 18:51:58 +0400 Message-ID: <20040420145158.GC1579@backtop.namesys.com> References: <20040416203937.GY14134@nysv.org> <26F302F3-9042-11D8-8B4A-000A95CD704C@wagland.net> <2EB65FD6-924A-11D8-8B4A-000A95CD704C@wagland.net> <16516.54935.159587.423283@laputa.namesys.com> <61B07E02-92A8-11D8-8B4A-000A95CD704C@wagland.net> <16517.10147.704572.959551@laputa.namesys.com> Mime-Version: 1.0 Return-path: list-help: list-unsubscribe: list-post: Errors-To: flx@namesys.com Content-Disposition: inline In-Reply-To: <16517.10147.704572.959551@laputa.namesys.com> List-Id: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Nikita Danilov Cc: Paul Wagland , reiserfs-list@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.