Stephen, To answer your question, the problem seems to be reproductible only in asynchronous mode (without O_SYNC). I have reproduced the case ( without O_SYNC) using different record sizes= : from 1 K to 64 K, but not with 512 bytes. It makes sense that the the zeroed holes in the file are caused by the nf= s client absence of serialisation/ ordering as the file is used in extensio= n. With O_SYNC i haven't reproduced the same problem for the moment. Regards, Eric NB: I always used mount with rsize =3D wsize =3D 8192. "Stephen C. Tweedie" a =E9crit : > Hi, > > On Wed, Jan 09, 2002 at 06:05:30PM +0100, eric chacron wrote: > > Hi Stephen, > > > > I use ext3 with kernel 2.4.14. I'm happy to have verified that nfs+ex= t3 > > in journal mode doesn't provide > > atomic write for the user point of view. > > > > My program writes sequential records of 64KB in a file through a nfs > > mount point. The blocks of data are > > initialized with a serie of integer: 1, 2, 3 ... > > I kill the nfsd daemons while two instance of the program are writing > > their 600 records of > > 64KB in two distinct files. > > Then using 'od' i look at the result, and i see some blocks of zero > > inside the file. The size of these zeroed blocks seems to be multiple > > of h'4000. > > NFS is a stateless protocol. It has absolutely no serialisation or > ordering in the protocol, so a given set of application writes can > easily get reordered on the wire (especially if you are running over > UDP and encounter any dropped packets.) > > The problem here is not ext3, but NFS. NFS simply does not make any > ordering guarantees at all. > > Is your application using O_SYNC or f[data]sync to impose ordering on > the data stream? > > Cheers, > Stephen > > _______________________________________________ > > Ext3-users@redhat.com > https://listman.redhat.com/mailman/listinfo/ext3-users
