Hi,
On 19 Oct 1999 00:44:38 -0500, [EMAIL PROTECTED] (Eric
W. Biederman) said:
> Meanwhile having the metadata in the page cache (where they would
> have predictable offsets by file size)
Doesn't help --- you still need to look up the physical block numbers
in order to clear the allocation bit
On Mon, 18 Oct 1999, Stephen C. Tweedie wrote:
>Data and metadata are completely different. On, say, a large and busy
>web or ftp server, you really don't care about a 1G metadata limit, but
>a 1G page cache limit is much more painful.
Sure I completly agree. It looked you was talking about s
Hi,
On 18 Oct 1999 08:20:51 -0500, [EMAIL PROTECTED] (Eric W. Biederman)
said:
>> And I still can't see how you can find the stale buffer in a
>> per-object queue as the object can be destroyed as well after the
>> lowlevel truncate.
> Yes but you can prevent the buffer from becomming a stale b
Hi,
On Mon, 18 Oct 1999 13:26:45 -0400 (EDT), Alexander Viro
<[EMAIL PROTECTED]> said:
>> You can't even know which is the inode Y that is using a block X without
>> reading all the inode metadata while the block X still belongs to the
>> inode Y (before the truncate).
> WTF would we _need_ to
Hi,
On Mon, 18 Oct 1999 13:26:45 -0400 (EDT), Alexander Viro
<[EMAIL PROTECTED]> said:
>> You can't even know which is the inode Y that is using a block X without
>> reading all the inode metadata while the block X still belongs to the
>> inode Y (before the truncate).
> WTF would we _need_ to
Hi,
On Mon, 18 Oct 1999 14:30:10 +0200 (CEST), Andrea Arcangeli
<[EMAIL PROTECTED]> said:
> I can't see these bigmem issues. The buffer and page-cache memory is not
> in bigmem anyway. And you can use bigmem _wherever_ you want as far as you
> remeber to fix all the involved code to kmap before
Hi,
On Sat, 16 Oct 1999 01:59:38 -0400 (EDT), Alexander Viro
<[EMAIL PROTECTED]> said:
a) to d), fine.
> e) we might get out with just a dirty blocks lists, but I think
> that we can do better than that: keep per-inode cache for metadata. It
> is going to be separate from the data pagecac
On Mon, 18 Oct 1999, Alexander Viro wrote:
>? The same way you are doing it with pagecache.
I think if I would have just understood I wouldn't be asking here ;).
>WTF would we _need_ to know? Think about it as about memory caching. You
>can cache by virtual address and you can cache by physical
On Mon, 18 Oct 1999, Andrea Arcangeli wrote:
> On Sat, 16 Oct 1999, Alexander Viro wrote:
>
> > c) Currently we keep the stuff for the first class around the page
> >cache and the rest in buffer cache. Large part of our problems comes
> >from the fact that we need to detect migration of bl
On Sat, 16 Oct 1999, Alexander Viro wrote:
> c) Currently we keep the stuff for the first class around the page
>cache and the rest in buffer cache. Large part of our problems comes
>from the fact that we need to detect migration of block from one class to
>another and scanning the whole bu
Stephen, I've looked through the current stuff with truncate()
(BTW, minixfs is broken too - rmdir() hangs solid) and I think that I have
a more-or-less tolerable solution. You definitely know the VFS/VM
interaction better (I'm mostly dealing with namespace side of the things),
so I'ld rea
11 matches
Mail list logo
