Message-Id: <200406101155.AA00203@tnesb9665.tnes.nec.co.jp>
From: Masanori TSUDA <tsuda@tnes.nec.co.jp>
Date: Thu, 10 Jun 2004 20:55:13 +0900
To: Nathan Scott <nathans@sgi.com>
Cc: linux-xfs@oss.sgi.com, Kazuyuki Goto <kazuyuki@sys1.cpg.sony.co.jp>
Subject: Re: data corruption on nfs+xfs
In-Reply-To: <20040610084803.GA620@frodo>
References: <20040610084803.GA620@frodo>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: linux-xfs-bounce@oss.sgi.com
Errors-to: linux-xfs-bounce@oss.sgi.com
Precedence: bulk
Content-Length: 1138
Lines: 40

Hi Nathan,

Thank you for commenting. 
I am glad to contribute to development of XFS. 

Regards,
Tsuda

In message "Re: data corruption on nfs+xfs" 
(04/06/10 17:48:03),
nathans@sgi.com wrote...
>On Thu, Jun 10, 2004 at 10:30:31AM +0900, Masanori TSUDA wrote:
>> Hi,
>
>Hi there,
>
>> I have reproduced similar problem on xfs1.3.1 (based on 2.4.21),
>> my environment is as follows.
>> 
>> I have investigated the issue using the kernel embeded local trace.
>> I think that the issue was caused by the delayed allocation mechanism.
>> I explain the example of curruption scenario which I guess.
>
>Thank you, and an excellent explanation too.  I think you may
>well have figured it out.
>
>> I think that one of solution for the issue is to flush only buffers in
>> end of the file before allocating disk space for delayed allocation blocks,
>> don't flush buffers over that.
>
>I'm sure Russell will have more to add tomorrow when he's
>awake.  I've ported your patch forward to current CVS (for
>2.4 and 2.6 kernels), for my own testing purposes and have
>included it below for anyone else who is interested.
>
>thanks!
>
>-- 
>Nathan