[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Oops, incomplete patch.

This archive contains answers to questions sent to Unidata support through mid-2025. Note that the archive is no longer being updated. We provide the archive for reference; many of the answers presented here remain technically correct, even if somewhat outdated. For the most up-to-date information on the use of NSF Unidata software and data services, please consult the Software Documentation first.

  • Subject: Re: Oops, incomplete patch.
  • Date: Thu, 05 Sep 2002 09:42:47 -0600
>To: Russ Rew <address@hidden>
>From: "Stonie R. Cooper" <address@hidden>
>Subject: Re: 20020730: The significance of pbuf_flush messages.
>Organization: Planetary Data
>Keywords: pbuf_flush-problem

Hi Stonie,

> No more pbuf_flush logs on ldm 5.2 . . . . 
> 
> There was a post by someone earlier about the incapatibility of ext3 and 
> Linux with the ldm queue . . . but I had assumed it dealt specifically with 
> ext3.
> 
> As we normally deal with very large file systems, I use reiserfs.  It's 
> great, it's fast, it's easy to deal with.
> 
> But it also doesn't play well with the ldm queue.  
> 
> . . . . after roughly a week of analysis . . . 
> 
> The kernel interrupts on that single file system (I dedicate a single 2GB 
> file system to a 1.7GB ldm queue - no other files are on that file system) 
> where ~100 times that of the LVM based reiserfs that was getting a lot more 
> data.  Even with a dual P-III, I was slowing everything way down, especially 
> services tied to that filesystem.
> 
> I haven't tried other jfs's . . . but considering the low complexity of the 
> single file system, I was silly not to make it a ext2 in the first place.
> 
> I have not gotten a single pbuf_flush message since shoving back to ext2 - 
> and I just tuned out the regularly scheduled fsck's with a tune2fs -c -1 on 
> that file system, so I can enjoy not having uninvited fsck'ers.  Sorry, 
> couldn't resist.
> 
> I generally stick on a problem . . . and wear it down.

Thanks for the information on this problem.  Here's my summary of what
you learned, let me know if I got it wrong:

  - On a Linux platfrom, use a simple ext2 file system partition for
    the LDM product queue, since reiserfs or ext3 will cause
    performance problems, with symptom lots of pbuf_flush messages.

  - For even better performance, turn off the periodic file system
    checking with "tunefs -c -1".

I'm still not sure if the patch we provided to LDM 5.2 is also needed,
but we're including it in 5.2.1 anyway ...

--Russ