--=_courier-19208-1045150531-0001-2
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable
Thanks, Andrew. So, no chances of getting this working correctly on 2.4
kernel for now (I mean, reading files with size !=3D n*block_size), and
I'd better give up on this... Is it the case, or you think there is
still something to do to get this working on ext2 and 2.4 kernel?
Bruno.
On Thu, 2003-02-13 at 00:12, Andrew Morton wrote:
> Bruno Diniz de Paula <diniz@cs.rutgers.edu> wrote:
> >
> > On Wed, 2003-02-12 at 19:13, Chris Wedgwood wrote:
> > > If I had to guess, write should work more or less the same as reads
> > > (ie. I should be able to write aligned-but-smaller-than-page-sized
> > > blocks to the end of files).
> > >=20
> > > Testing this however shows this is *not* the case.
> >=20
> > This is not the case, I have also tested here and the file written has
> > n*block_size always. The problem with writing is that we can't sign to
> > the kernel that the actual data has finished and from that point on it
> > should zero-fill the bytes. And what is worse, the information about th=
e
> > actual size is lost, since the write syscall will store what is passed
> > on the 3rd argument in the inode (field st_size of stat). This means
> > that after writing using O_DIRECT we can't read data correctly anymore.
> > The exception is when we write together with the data information about
> > the actual size and process disregarding information from stat, for
> > instance.
> >=20
> > Well, I am sure I am completely wrong because this doesn't make any
> > sense for me. Someone that has already dealt with this and can bring a
> > light to the discussion?
> >=20
>=20
> For writes, I don't think it is reasonable for the kernel to be have to
> handle byte-granular appends. O_DIRECT is different. For this case the
> application should ftruncate the file back to the desired size prior to
> closing it.
>=20
> For the short reads at EOF, the 2.4 kernel refuses to read anything, and
> returns zero. The 2.5 kernel will return -EINVAL, which is better behavi=
our
> (shouldn't make it just look like the file is shorter than it really is).
>=20
> The ideal behaviour is that which I mistakenly described previously: we
> should fill with zeroes and return the partial result. I'll look at
> converting 2.5 to do that. As long as the changes are small - the direct=
-io
> code does a ton of stuff, is complex, is not tested a lot and breakage te=
nds
> to be subtle.
--=20
Bruno Diniz de Paula <diniz@cs.rutgers.edu>
Rutgers University
--=_courier-19208-1045150531-0001-2
Content-Type: application/pgp-signature; name="signature.asc"
Content-Transfer-Encoding: 7bit
Content-Description: This is a digitally signed message part
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)
iD8DBQA+S7gXZGORSF4wrt8RAnrnAKCMcX/efG6/QHZtxRivhYkzDqNgogCfTD0S
C+kJ69plgLAZO1TPMKNlYnw=
=4qEQ
-----END PGP SIGNATURE-----
--=_courier-19208-1045150531-0001-2--