--E39vaYmALEf/7YXx
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Fri, Oct 15, 2004 at 07:33:05PM +1000, Daniel Carosone wrote:
> On Thu, Oct 14, 2004 at 06:51:17AM -0700, Bill Studenmund wrote:
> > > Essentially, "if I call fsync now, how much disk traffic will I
> > > cause?".
> >=20
> > I don't know of an easy way to get this info.
>=20
> I'm not sure one exists, but someone can tell us otherwise.. :)

Let me rephrase that. I've done a lot of work with file systems, and I've=
=20
not seen anything that would easily get us this info. So that was an=20
expert, "I don't know how to do this," not an, "I don't know this=20
subsystem well" I don't know. :-)

> > We'd have to ask the file system. Because in addition to writing
> > dirty pages, you may have to write metadata out, which only the file
> > system will be able to add up.
>=20
> True, if it should count metadata. The flippant fsync disk traffic
> example was probably a poor one, because I don't think it should
> (would you count TCP and IP headers for a socket?).

I agree. The main point I was trying to make is that we need to think=20
about our definition. Things like, "Amount of space in the send queue" or=
=20
"amount of data in the send queue" are really clear. Everything else isn't=
=20
so clear, and if we (well if I) think about it for a while, everything=20
else turns into a twisty maze.

> > But 0 isn't a lie. ;-) All of the bytes written to the file have made i=
t=20
> > to the file. Perhaps not the disk image of the file, but the kernel ima=
ge=20
> > of the file has them. :-) Anywhere in the file that you read, you will =
see=20
> > the bytes you wrote.
>=20
> I'm not sure that's true in all cases for things like NFS, smbfs, or
> some shared-disk cluster filesystem (like solaris' mount -o global),
> or probably some other perverse cases (that will be even harder to
> come up with the correct figure above :)

Ahhh, but they are in the file as the kernel understands it, aren't they?=
=20
:-) While I find the turns you're taking with the discussion not=20
unreasonable, I think the biggest thing about them is that they indicate=20
that we really should just avoid such semantics.

Take care,

Bill

--E39vaYmALEf/7YXx
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (NetBSD)

iD8DBQFBdBzDWz+3JHUci9cRAhloAJwI0EnK6O3eTczZ1Vzie9KzciMdHgCeJj2H
YZYxw43IhYgHtTQ+7Nf4MmE=
=oS2A
-----END PGP SIGNATURE-----

--E39vaYmALEf/7YXx--