[Top] [All Lists]

Re: [PATCH] page_buf stuff

To: Russell Cattelan <cattelan@xxxxxxxxxxx>
Subject: Re: [PATCH] page_buf stuff
From: Luben Tuikov <luben@xxxxxxxxxxxx>
Date: Wed, 30 Oct 2002 18:53:34 -0500
Cc: linux-xfs <linux-xfs@xxxxxxxxxxx>
Organization: Splentec Ltd.
References: <3DBE3924.22B019A1@xxxxxxxxxxxx> <1035899015.9794.13.camel@xxxxxxxxxxxxxxxxxxxxxxx> <3DBF2B37.3440673D@xxxxxxxxxxxx> <20021030005632.A9930@xxxxxxxxxxxxx> <3DBF7E2F.57C503D@xxxxxxxxxxxx> <20021030115210.A24361@xxxxxxxxxxxxx> <3DC067F9.192BFE9C@xxxxxxxxxxxx> <1036020949.19627.1655.camel@xxxxxxxxxxxxxxxxxxxxx>
Sender: linux-xfs-bounce@xxxxxxxxxxx
Russell Cattelan wrote:
> So if you has actually said something that would suggest you know how
> to program we might have actually considered you a programmer. :-)
> (clever syntax a programmer does not make)

Yet another professional. 

Sorry, my drivers don't oops, and do make mount go in D state indefinitely.

Take a look at pagebuf/*.c -- this can definitely be cleaned up.
Don't you agree? (<-- careful what you answer here if your boss knows C)
> Ohh and for the record and to back up what Christoph said your
> interpretation of BH_Dirty is incorrect, his is.

Really? But look:

> > If the buffer should be written out, the dirty bit should be turned on.
> > This makes sense anywhich way you look at it and think about it.
> > This makes sense from 1. the code I've seen in the kernel (md)
> > and from 2. logical point of view and from 3. my old OS course textbook
> > (``the dinosaur book'').

> It makes sense if you let the VM control the write out, but pagebuf
> does the writeout explicit and the bit doesn't matter at all.

So, he *does* say that it makes sense.
Let's just do what makes sense -- that's all I'm saying.
Take a look at the md code (mirroring, 2.4). Don't give me 2.5
as an example (which uses bios) -- it would be a red-herring.


<Prev in Thread] Current Thread [Next in Thread>