PG_updatodate vs BH_updatodate

PG_updatodate vs BH_updatodate

[Francis Moreau]

Hello,

I'm wondering if there's any difference between these 2 flags except
that one is a page flag and the other one is a buffer head flag.

But in my understanding these 2 flags means that the page contains
uptodate data. So the buffer head flag seems useless since it could be
calculated from bh->b_page->flags.

Thanks for any hints

Francis

Re: PG_updatodate vs BH_updatodate

[Andreas Dilger]

On Nov 21, 2008  23:03 +0100, Francis Moreau wrote:
> I'm wondering if there's any difference between these 2 flags except
> that one is a page flag and the other one is a buffer head flag.
> 
> But in my understanding these 2 flags means that the page contains
> uptodate data. So the buffer head flag seems useless since it could be
> calculated from bh->b_page->flags.

There may be multiple buffers on a single page, and in some cases one
buffer on a page can be uptodate while another buffer on the same page
is not.  This can be confusing at times, but I don't know if there is
any easy way to avoid it.

Cheers, Andreas
--
Andreas Dilger
Sr. Staff Engineer, Lustre Group
Sun Microsystems of Canada, Inc.

Re: PG_updatodate vs BH_updatodate

[Francis Moreau]

Hello,

Thanks for your answer.

Andreas Dilger <adilger@sun.com> writes:

> There may be multiple buffers on a single page, and in some cases
> one buffer on a page can be uptodate while another buffer on the
> same page is not.

Can this really happen ?

Are there any cases where a page can be partially uptodate ?

Francis

Re: PG_updatodate vs BH_updatodate

[Matthew Wilcox]

On Sun, Nov 23, 2008 at 01:14:52PM +0100, Francis Moreau wrote:
> Hello,
> 
> Thanks for your answer.
> 
> Andreas Dilger <adilger@sun.com> writes:
> 
> > There may be multiple buffers on a single page, and in some cases
> > one buffer on a page can be uptodate while another buffer on the
> > same page is not.
> 
> Can this really happen ?

Yes.

> Are there any cases where a page can be partially uptodate ?

Consider a filesystem with 1k blocks and a system with a page size of 4k.
You have a buffer_head for each of the four blocks that are being kept
in the page, and you want to track their dirty state independently.

For file data, no this doesn't happen.  But for metadata, it happens
quite easily.

-- 
Matthew Wilcox				Intel Open Source Technology Centre
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours.  We can't possibly take such
a retrograde step."

Re: PG_updatodate vs BH_updatodate

[Francis Moreau]

Matthew Wilcox <matthew@wil.cx> writes:

> On Sun, Nov 23, 2008 at 01:14:52PM +0100, Francis Moreau wrote:
>
>> Are there any cases where a page can be partially uptodate ?
>
> Consider a filesystem with 1k blocks and a system with a page size of 4k.
> You have a buffer_head for each of the four blocks that are being kept
> in the page, and you want to track their dirty state independently.

Sorry but I'm confused since you're taking about the dirty state
(tracked by BH_Dirty bit) and I was taking about the uptodate state
(tracked by BH_Uptodate bit).

>
> For file data, no this doesn't happen.  But for metadata, it happens
>quite easily.

Could you give me an example of these metadata ?

Thanks

Francis

Re: PG_updatodate vs BH_updatodate

[Jörn Engel]

On Sun, 23 November 2008 21:14:47 +0100, Francis Moreau wrote:
> Matthew Wilcox <matthew@wil.cx> writes:
> > On Sun, Nov 23, 2008 at 01:14:52PM +0100, Francis Moreau wrote:
> >
> >> Are there any cases where a page can be partially uptodate ?
> >
> > Consider a filesystem with 1k blocks and a system with a page size of 4k.
> > You have a buffer_head for each of the four blocks that are being kept
> > in the page, and you want to track their dirty state independently.
> 
> Sorry but I'm confused since you're taking about the dirty state
> (tracked by BH_Dirty bit) and I was taking about the uptodate state
> (tracked by BH_Uptodate bit).

Think page cache, except that the granularity is not pages but 1k
blocks.  If your filesystem wants to read an indirect block, 1k is read
into the cache, the other 3k (or 63k) of the page remain as they were.

If you have to cache data on a granularity smaller than a page, as many
filesystems, your only alternative would be to leave the remaining 3k
(or 63k) empty - a rather wasteful approach.

Jörn

-- 
A surrounded army must be given a way out.
-- Sun Tzu
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: PG_updatodate vs BH_updatodate

[Francis Moreau]

On Mon, Nov 24, 2008 at 4:56 PM, Jörn Engel <joern@logfs.org> wrote:
> On Sun, 23 November 2008 21:14:47 +0100, Francis Moreau wrote:
>> Matthew Wilcox <matthew@wil.cx> writes:
>> > On Sun, Nov 23, 2008 at 01:14:52PM +0100, Francis Moreau wrote:
>> >
>> >> Are there any cases where a page can be partially uptodate ?
>> >
>> > Consider a filesystem with 1k blocks and a system with a page size of 4k.
>> > You have a buffer_head for each of the four blocks that are being kept
>> > in the page, and you want to track their dirty state independently.
>>
>> Sorry but I'm confused since you're taking about the dirty state
>> (tracked by BH_Dirty bit) and I was taking about the uptodate state
>> (tracked by BH_Uptodate bit).
>
> Think page cache, except that the granularity is not pages but 1k
> blocks.  If your filesystem wants to read an indirect block, 1k is read
> into the cache, the other 3k (or 63k) of the page remain as they were.
>

So if I understand you correctly, we can update a page cache partially
only when the
filesystems needs to read its metadata. But not when reading a page of data.

That's pretty what Matthew answered I think but I'm confused about the
dirty bit of the
buffer header he mentioned.

Thanks
-- 
Francis
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html