"Stephen C. Tweedie" wrote:
> Hi,
>
> On Fri, 07 Jan 2000 00:32:48 +0300, Hans Reiser <[EMAIL PROTECTED]> said:
>
> > Andrea Arcangeli wrote:
> >> BTW, I thought Hans was talking about places that can't sleep (because of
> >> some not schedule-aware lock) when he said "place that cannot call
> >>
On Fri, 7 Jan 2000, Stephen C. Tweedie wrote:
>Fine, I was just looking at it from the VFS point of view, not the
>specific filesystem. In the worst case, a filesystem can always simply
>defer marking the buffer as dirty until after the locking window has
>passed, so there's obviously no fundame
Hi,
On Fri, 07 Jan 2000 00:32:48 +0300, Hans Reiser <[EMAIL PROTECTED]> said:
> Andrea Arcangeli wrote:
>> BTW, I thought Hans was talking about places that can't sleep (because of
>> some not schedule-aware lock) when he said "place that cannot call
>> balance_dirty()".
> You were correct. I
Hi,
On Thu, 6 Jan 2000 20:25:38 -0500 (EST), "Albert D. Cahalan"
<[EMAIL PROTECTED]> said:
> AIX has such an API already. It is good to clone if you can.
The AIX API is much more than a simple small-operation atomic
transaction API, isn't it? The filesystem transactions have many
properties --
Hans Reiser writes:
> Yes, but not before 2.5. Chris and I have already discussed that
> it would be nice to make the transaction API available to user space,
> but we haven't done any work on it, or even specified the user API.
AIX has such an API already. It is good to clone if you can.
This
Andrea Arcangeli wrote:
> BTW, I thought Hans was talking about places that can't sleep (because of
> some not schedule-aware lock) when he said "place that cannot call
> balance_dirty()".
You were correct. I think Stephen and I are missing in communicating here.
--
Get Linux (http://www.kern
BTW, I thought Hans was talking about places that can't sleep (because of
some not schedule-aware lock) when he said "place that cannot call
balance_dirty()".
On Thu, 6 Jan 2000, Stephen C. Tweedie wrote:
>It shouldn't be impossible: as long as we are protected against
>recursive invocations of
Hi,
On Thu, 23 Dec 1999 06:41:44 +0800, Tan Pong Heng
<[EMAIL PROTECTED]> said:
> I was thinking that, unless you want to have FS specific buffer/page
> cache, there is alway a gain for a unified cache for all fs. I think
> the one piece of functionality missing from the 2.3 implementation
> is
Hi,
On Thu, 23 Dec 1999 02:37:48 +0300, Hans Reiser <[EMAIL PROTECTED]>
said:
>> > I completly agree to change mark_buffer_dirty() to call balance_dirty()
>> > before returning.
> How can we use a mark_buffer_dirty that calls balance_dirty in a
> place where we cannot call balance_dirty?
It sh
Tigran Aivazian wrote:
> On Wed, 5 Jan 2000, Peter J. Braam wrote:
> > I think I mean joining. What I need is:
> >
> > braam starts trans
> >does A
> >calls reiser: hans starts
> >does B
> >hans commits; nothing goes to disk yet
> >braam does C
> > braam commits/aborts ABC n
Yes, but not before 2.5. Chris and I have already discussed that it would be
nice to make the transaction API available to user space, but we haven't done any
work on it, or even specified the user API. We probably won't even start work on
it for 6 months (unless a sponsor asks for it). We do t
On Wed, 5 Jan 2000, Peter J. Braam wrote:
> I think I mean joining. What I need is:
>
> braam starts trans
>does A
>calls reiser: hans starts
>does B
>hans commits; nothing goes to disk yet
>braam does C
> braam commits/aborts ABC now go or don't
>
>
Reiserfs won't do
On Wed, 5 Jan 2000, Peter J. Braam wrote:
> I think I mean joining. What I need is:
>
> braam starts trans
>does A
>calls reiser: hans starts
>does B
>hans commits; nothing goes to disk yet
>braam does C
> braam commits/aborts ABC now go or don't
no, that definitely looks
I think I mean joining. What I need is:
braam starts trans
does A
calls reiser: hans starts
does B
hans commits; nothing goes to disk yet
braam does C
braam commits/aborts ABC now go or don't
- Peter -
On Wed, 5 Jan 2000, Hans Reiser wrote:
> Is nesting really the term you
Erez Zadok wrote:
>
> Hans and linux-fsdevel folks: I have a proposal. How would you all feel
> forming an informal group that would report changes relevant to f/s
> developers on this list. (Maybe even a different mailing list?)
I think that sending emails summarizing changes to the kernel ot
Is nesting really the term you mean to use here, or is joining the term you
mean?
Do you really mean transactions within other transactions?
Exactly what functionality do you need?
Hans
"Peter J. Braam" wrote:
> Hi,
>
> I have one request for the journal API for use by network file systems -
Hi,
I have one request for the journal API for use by network file systems -
it is a request of a slightly different nature than the ones discussed so
far.
InterMezzo (www.inter-mezzo.org) exploits an existing disk file system as
a cache and wraps around it. (Any disk file system can be used,
On Tue, 21 Dec 1999, Benjamin C.R. LaHaise wrote:
>The buffer dirty lists are the wrong place to be dealing with this. We
The only reason for not using buffer.c is to make sure to not insert bugs
in such file.
>need a lightweight, fast way of monitoring the system's dirty buffer/page
The ligh
Hi guys,
Although I received a few nice replies privately, I think it makes sense
to clarify what I meant when I said "Jeff's comments irritate me".
I meant that we should put a lot more work into writing kernel
commentaries like the excellent one started by Neil Brown on VFS and nfsd
already (d
In message <[EMAIL PROTECTED]>,
Jeff Garzik writes:
>
[...]
> To sum, documenting changes is a very good idea, notifying specific
> hackers of specific kernel changes is a waste of time [unless they
> are the maintainers of the code being changed, of course].
I agree that notifying individuals
(copied to linux-kernel)
On Sun, 26 Dec 1999, Erez Zadok wrote:
> In message <[EMAIL PROTECTED]>,
>Jeff Garzik writes:
> > On Thu, 23 Dec 1999, Hans Reiser wrote:
> > > All I'm going to ask is that if mark_buffer_dirty gets changed again,
> > > whoever changes it please let us know this time...
May I ask why the time is O(N*Log(N)) instead of O(Log(N)). We have this
interesting OS class implementing a AVL tree structured directory entry in
ext2 directory file on disk. I always think it is not going to work out.
But the TA and the professor keep telling me the new file system will be
bett
In message <[EMAIL PROTECTED]>,
Jeff Garzik writes:
> On Thu, 23 Dec 1999, Hans Reiser wrote:
> > All I'm going to ask is that if mark_buffer_dirty gets changed again,
> > whoever changes it please let us know this time. The last two times
> > it was changed we weren't informed, and the fir
May I ask why the time is O(N*Log(N)) instead of O(Log(N)). We have this
interesting OS class implementing a AVL tree structured directory entry in
ext2 directory file on disk. I always think it is not going to work out.
But the TA and the professor keep telling me the new file system will be
bett
On Thu, 23 Dec 1999, Jeff Garzik wrote:
> Can't you figure this sort of thing out on your own?
..
> And grep'ing patches ain't that hard
Jeff, with all respect to your great kernel hacking talents - these sort
of comments really irritate me. Most (I assume) kernel hackers have
full-time jobs
On Thu, 23 Dec 1999, Hans Reiser wrote:
> All I'm going to ask is that if mark_buffer_dirty gets changed again, whoever
> changes it please let us know this time. The last two times it was changed
> we weren't informed, and the first time it happened it took a long time to
> figure it out.
C
All I'm going to ask is that if mark_buffer_dirty gets changed again, whoever
changes it please let us know this time. The last two times it was changed
we weren't informed, and the first time it happened it took a long time to
figure it out.
I think that whether we make __mark_buffer_dirty
On Thu, 23 Dec 1999, Hans Reiser wrote:
>If reiserfs had good SMP, you could stall it anywhere, and the code
>could handle that. But we don't, and I bet others also don't, and we
>won't have it for some time even though we are working on it.
I completly understand that we need also an atomic ma
On Wed, 22 Dec 1999, William J. Earl wrote:
>in the extent. If the page cache were indexed by a per-inode AVL tree
Some month ago I did some research in putting the pagecache into a
per-inode RB-tree. AVL would be overkill because insert/removal can be the
only operation done on the tree (with
"Benjamin C.R. LaHaise" wrote:
> I completly agree to change mark_buffer_dirty() to call balance_dirty()
> > before returning. But if you add the balance_dirty() calls all over the
> > right places all should be _just_ fine as far I can tell.
>
> I don't agree, both for the reasons above and bec
Stephen's remarks seem right to me.
Hans
--
Get Linux (http://www.kernel.org) plus ReiserFS
(http://devlinux.org/namesys). If you sell an OS or
internet appliance, buy a port of ReiserFS! If you
need customizations and industrial grade support, we sell them.
Tan Pong Heng writes:
...
> I was thinking that, unless you want to have FS specific buffer/page cache,
> there is alway a gain for a unified cache for all fs. I think the one piece
> of functionality missing from the 2.3 implementation is the dependency
> between the various pages. If you cou
"Stephen C. Tweedie" wrote:
> Hi,
>
> On Tue, 21 Dec 1999 11:18:03 +0100 (CET), Andrea Arcangeli
> <[EMAIL PROTECTED]> said:
>
> > On Tue, 21 Dec 1999, Stephen C. Tweedie wrote:
> >> refile_buffer() checks in buffer.c. Ideally there should be a
> >> system-wide upper bound on dirty data: if each
"Stephen C. Tweedie" wrote:
> Hi,
>
> On Tue, 21 Dec 1999 20:21:05 -0500 (EST), "Benjamin C.R. LaHaise"
> <[EMAIL PROTECTED]> said:
>
> > The buffer dirty lists are the wrong place to be dealing with this. We
> > need a lightweight, fast way of monitoring the system's dirty buffer/page
> > thres
Hi,
On Tue, 21 Dec 1999 20:21:05 -0500 (EST), "Benjamin C.R. LaHaise"
<[EMAIL PROTECTED]> said:
> The buffer dirty lists are the wrong place to be dealing with this. We
> need a lightweight, fast way of monitoring the system's dirty buffer/page
> thresholds -- one that can be called for every w
On Tue, 21 Dec 1999, Andrea Arcangeli wrote:
> On Tue, 21 Dec 1999, Stephen C. Tweedie wrote:
>
> >refile_buffer() checks in buffer.c. Ideally there should be a
> >system-wide upper bound on dirty data: if each different filesystem
> >starts to throttle writes at 50% of physical mem
Hi,
On Tue, 21 Dec 1999 14:57:29 +0100 (CET), Andrea Arcangeli
<[EMAIL PROTECTED]> said:
> So you are talking about replacing this line:
> dirty = size_buffers_type[BUF_DIRTY] >> PAGE_SHIFT;
> with:
> dirty = (size_buffers_type[BUF_DIRTY]+size_buffers_type[BUF_PINNED]) >>
>PAGE_SHIF
On Tue, 21 Dec 1999, Stephen C. Tweedie wrote:
>We cannot use the buffer.c dirty list anyway because bdflush can write
>those buffers to disk at any time. Transactions have to control the
So you are talking about replacing this line:
dirty = size_buffers_type[BUF_DIRTY] >> PAGE_SHIFT;
Hi,
On Tue, 21 Dec 1999 11:18:03 +0100 (CET), Andrea Arcangeli
<[EMAIL PROTECTED]> said:
> On Tue, 21 Dec 1999, Stephen C. Tweedie wrote:
>> refile_buffer() checks in buffer.c. Ideally there should be a
>> system-wide upper bound on dirty data: if each different filesystem
>> starts to throttle
On Tue, 21 Dec 1999, Stephen C. Tweedie wrote:
>refile_buffer() checks in buffer.c. Ideally there should be a
>system-wide upper bound on dirty data: if each different filesystem
>starts to throttle writes at 50% of physical memory then you only
>need two different filesystems to
Hi,
All comments welcome: this is a first draft outline of what I _think_
Linus is asking for from journaling for mainline kernels.
On Wed, 15 Dec 1999 13:45:22 -0500, Chris Mason
<[EMAIL PROTECTED]> said:
> What is your current plan for porting ext3 into 2.3/2.4? Are you still
> going to be b
41 matches
Mail list logo
