Re: logbufs=8,logbsize=32768

[Seth Mos <knuffie@xxxxxxxxx>]

At 09:51 27-2-2003 +0100, Marc Schmitt wrote:
> Hi all,
>
> I'm using the latest stable release 1.2.0 with kernel 2.4.19 under RedHat 7.3.
>
> As stated in the XFS FAQ, tuning the logbufs/logbsize values have a big 
> impact on the delete performance. After running some bonnie++s, it's 
> obvious that the impact is huge.
>
> The mount options given in the subject are memory greedy, the FAQ says, on 
> a 128MB RAM system, it is likely to fail.

This is actually not quite correct anymore and comes from the pre 1.1 days. 
The amount of memory XFS allocates has been significantly reduced over time.

> What does the memory consumption depend on? Is there a formula to roughly 
> calculate the memory consumed with those mount options per mounted file system?

Well, I observed mount failing with 128MB on my testbox at that time and 
put a warning in the FAQ that just raising the value might result in failure.

Cheers

--
Seth
It might just be your lucky day, if you only knew.


rom owner-linux-xfs@xxxxxxxxxxx Thu Feb 27 09:26:09 2003
Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 27 Feb 2003 09:26:14 
-0800 (PST)
Received: from core.inf.ethz.ch (root@xxxxxxxxxxxxxxxx [129.132.178.196])
        by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1RHQ7eA001445
        for <linux-xfs@xxxxxxxxxxx>; Thu, 27 Feb 2003 09:26:08 -0800
Received: from inf.ethz.ch 
(IDENT:WAAtjkoCiRiGs2oken+/doYdOUxHVBn0@xxxxxxxxxxxxxxxxxx [129.132.10.58])
        by core.inf.ethz.ch (8.9.3/8.9.3) with ESMTP id QAA17978;
        Thu, 27 Feb 2003 16:49:12 +0100 (MET)
Message-ID: <3E5E3377.2060109@xxxxxxxxxxx>
Date: Thu, 27 Feb 2003 16:49:11 +0100
From: Marc Schmitt <schmitt@xxxxxxxxxxx>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 
Netscape/7.01
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Stephen Lord <lord@xxxxxxx>
CC: linux-xfs@xxxxxxxxxxx, knuffie@xxxxxxxxx
Subject: Re: logbufs=8,logbsize=32768
References: <3E5DD19E.6030600@xxxxxxxxxxx> 
<1046350347.2227.1.camel@xxxxxxxxxxxxxxxxxxxxx>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-archive-position: 2953
X-ecartis-version: Ecartis v1.0.0
Sender: linux-xfs-bounce@xxxxxxxxxxx
Errors-to: linux-xfs-bounce@xxxxxxxxxxx
X-original-sender: schmitt@xxxxxxxxxxx
Precedence: bulk
X-list: linux-xfs

Stephen Lord wrote:
> On Thu, 2003-02-27 at 02:51, Marc Schmitt wrote:
>
> Its really simple:
>
>         8 * 32K or 256K per filesystem that you use these options on.
>
> Usually no problem unless memory is tight at the time of mount. These
> options do not make sense unless that filesystem is under constant
> heavy metadata load.

Thanks for the answers, Seth and Steve. I'm not sure what you mean by 
heavy metadata load, sorry. What produces such load? Databases? Home 
directories of a whole bunch of users on the same partition?

In an earlier post (Re: Best Logfile size for XFS; 02/11/2002), Steve wrote:
> There is no hard and fast rule for this, a larger log is only really useful if 
> you
> are doing metadata intensive operations over extended periods of time and
> we have found that more iclogs are just as useful (the logbugs=8 mount option).
> I cannot remember right now, but mkfs may automatically make the
> log bigger on large devices, of course large may be past the 2 Tbyte limit
> on linux.
>
> For write performance a larger log will not help, more iclogs might, but
> not by much.
>
> The other thing to consider with larger logs is that recovery after a crash
> can take longer.

Logbufs are in memory only, right? If yes, the more I have, the more 
information gets lost on a crash, the higher the chance of heavy 
filesystem corruption, correct?

Seth, judging by the number and content of your posts on this list, you 
must have XFS in production for ages. :)
What mount options do you recommend or did you come up with for your 
different needs (I assume you're using XFS for different services)?

TIA

Regards,
        Marc





rom owner-linux-xfs@xxxxxxxxxxx Thu Feb 27 09:34:05 2003
Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 27 Feb 2003 09:34:10 -0800 (PST)
Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101])
	by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1RHY5eA001980
	for <linux-xfs@xxxxxxxxxxx>; Thu, 27 Feb 2003 09:34:05 -0800
Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134])
	by zok.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h1RCrRKp009383
	for <linux-xfs@xxxxxxxxxxx>; Thu, 27 Feb 2003 04:53:27 -0800
Received: from tulip-e236.americas.sgi.com (tulip-e236.americas.sgi.com [128.162.236.208]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id GAA26749; Thu, 27 Feb 2003 06:53:26 -0600 (CST)
Received: from [192.168.1.100] (cf-vpn-sw-corp-64-52.corp.sgi.com [134.15.64.52]) by tulip-e236.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.8) with ESMTP id GAA75306; Thu, 27 Feb 2003 06:53:25 -0600 (CST)
Subject: Re: logbufs=8,logbsize=32768
From: Stephen  Lord <lord@xxxxxxx>
To: Marc Schmitt <schmitt@xxxxxxxxxxx>
Cc: linux-xfs@xxxxxxxxxxx
In-Reply-To: <3E5DD19E.6030600@xxxxxxxxxxx>
References: <3E5DD19E.6030600@xxxxxxxxxxx>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
X-Mailer: Ximian Evolution 1.0.3 (1.0.3-6) 
Date: 27 Feb 2003 06:52:26 -0600
Message-Id: <1046350347.2227.1.camel@xxxxxxxxxxxxxxxxxxxxx>
Mime-Version: 1.0
X-archive-position: 2954
X-ecartis-version: Ecartis v1.0.0
Sender: linux-xfs-bounce@xxxxxxxxxxx
Errors-to: linux-xfs-bounce@xxxxxxxxxxx
X-original-sender: lord@xxxxxxx
Precedence: bulk
X-list: linux-xfs

On Thu, 2003-02-27 at 02:51, Marc Schmitt wrote:
> Hi all,
>
> I'm using the latest stable release 1.2.0 with kernel 2.4.19 under 
> RedHat 7.3.
>
> As stated in the XFS FAQ, tuning the logbufs/logbsize values have a big 
> impact on the delete performance. After running some bonnie++s, it's 
> obvious that the impact is huge.
>
> The mount options given in the subject are memory greedy, the FAQ says, 
> on a 128MB RAM system, it is likely to fail.
>
> What does the memory consumption depend on? Is there a formula to 
> roughly calculate the memory consumed with those mount options per 
> mounted file system?

Its really simple:

        8 * 32K or 256K per filesystem that you use these options on.

Usually no problem unless memory is tight at the time of mount. These
options do not make sense unless that filesystem is under constant
heavy metadata load.

Steve



rom owner-linux-xfs@xxxxxxxxxxx Thu Feb 27 09:45:03 2003
Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 27 Feb 2003 09:45:08 
-0800 (PST)
Received: from smtpzilla2.xs4all.nl (smtpzilla2.xs4all.nl [194.109.127.138])
        by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1RHj2eA006431
        for <linux-xfs@xxxxxxxxxxx>; Thu, 27 Feb 2003 09:45:03 -0800
Received: from auto-nb1.xs4all.nl (coltex.xs4all.nl [213.84.127.28])
        by smtpzilla2.xs4all.nl (8.12.0/8.12.0) with ESMTP id h1RGQbME092979;
        Thu, 27 Feb 2003 17:26:38 +0100 (CET)
Message-Id: <4.3.2.7.2.20030227170429.03759028@xxxxxxxxxxxxx>
X-Sender: knuffie@xxxxxxxxxxxxx
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Thu, 27 Feb 2003 17:26:28 +0100
To: Marc Schmitt <schmitt@xxxxxxxxxxx>, Stephen Lord <lord@xxxxxxx>
From: Seth Mos <knuffie@xxxxxxxxx>
Subject: Re: logbufs=8,logbsize=32768
Cc: linux-xfs@xxxxxxxxxxx
In-Reply-To: <3E5E3377.2060109@xxxxxxxxxxx>
References: <3E5DD19E.6030600@xxxxxxxxxxx>
<1046350347.2227.1.camel@xxxxxxxxxxxxxxxxxxxxx>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-archive-position: 2955
X-ecartis-version: Ecartis v1.0.0
Sender: linux-xfs-bounce@xxxxxxxxxxx
Errors-to: linux-xfs-bounce@xxxxxxxxxxx
X-original-sender: knuffie@xxxxxxxxx
Precedence: bulk
X-list: linux-xfs

At 16:49 27-2-2003 +0100, Marc Schmitt wrote:
> Stephen Lord wrote:
> Thanks for the answers, Seth and Steve. I'm not sure what you mean by 
> heavy metadata load, sorry. What produces such load? Databases? Home 
> directories of a whole bunch of users on the same partition?

Heavy metadata load is the amount of changes that are done to the filesystem.
So updating one 1GB file is a low metadata operation but updating 1 million 
files of 1KB is a high metadata load.

The size of the file does not matter since metadata implies that the data 
it self is not journalled.

> Logbufs are in memory only, right? If yes, the more I have, the more 
> information gets lost on a crash, the higher the chance of heavy 
> filesystem corruption, correct?

Not corruption, but the amount of changes pending to be committed to disk 
might get lost resulting in missing files or a damaged file. Remember the 
filesystem stays in tact, but you will also need to have the database 
software (if you run it) to have transaction support or other crash 
recovery mechanisms to cope with the loss.

> Seth, judging by the number and content of your posts on this list, you 
> must have XFS in production for ages. :)
> What mount options do you recommend or did you come up with for your 
> different needs (I assume you're using XFS for different services)?

I have one "large" database server which is running Red Hat Linux 7.3 with 
the XFS 1.2 release kernels I made myself. So far the machine has been in 
production for over a year. The machine is a dual 1.13Ghz PIII with 2GB ram 
and a 200GB hardware raid 10. The database software we use is Progres 
version 9.1C (pending 9.1D).

The largest filesystem we have is the /users filesystem which also houses 
the home directories which are NFS exported. This filesystem is roughly 
180GB large. We mount this filesystem with logbufs=8 to make the database 
response faster. Remember that the database must support the ability to 
perform crash recovery as well.
XFS does the filesystem integrity and Progres performs the database integrity.

We created this filesystem with a larger log (mkfs.xfs -l size=32768b 
/dev/foo). Although the filesystem is located on a hardware raid I did not 
perform stripunit and stripwidth tuning yet which should help performance 
even more.

Cheers

--
Seth
It might just be your lucky day, if you only knew.


rom owner-linux-xfs@xxxxxxxxxxx Thu Feb 27 10:08:30 2003
Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 27 Feb 2003 10:08:35 -0800 (PST)
Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101])
	by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1RI8TeA007159
	for <linux-xfs@xxxxxxxxxxx>; Thu, 27 Feb 2003 10:08:29 -0800
Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134])
	by zok.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h1RFsJKp008788
	for <linux-xfs@xxxxxxxxxxx>; Thu, 27 Feb 2003 07:54:19 -0800
Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id JAA42449; Thu, 27 Feb 2003 09:54:18 -0600 (CST)
Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.232.100]) by daisy-e236.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id JAA34282; Thu, 27 Feb 2003 09:54:18 -0600 (CST)
Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id h1RFsIc20035; Thu, 27 Feb 2003 09:54:18 -0600
Subject: Re: logbufs=8,logbsize=32768
From: Steve Lord <lord@xxxxxxx>
To: Marc Schmitt <schmitt@xxxxxxxxxxx>
Cc: linux-xfs@xxxxxxxxxxx, Seth Mos <knuffie@xxxxxxxxx>
In-Reply-To: <3E5E3377.2060109@xxxxxxxxxxx>
References: <3E5DD19E.6030600@xxxxxxxxxxx>
	 <1046350347.2227.1.camel@xxxxxxxxxxxxxxxxxxxxx>
	 <3E5E3377.2060109@xxxxxxxxxxx>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Organization: 
Message-Id: <1046361258.17393.221.camel@xxxxxxxxxxxxxxxxxxxx>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.2.1 
Date: 27 Feb 2003 09:54:18 -0600
X-archive-position: 2956
X-ecartis-version: Ecartis v1.0.0
Sender: linux-xfs-bounce@xxxxxxxxxxx
Errors-to: linux-xfs-bounce@xxxxxxxxxxx
X-original-sender: lord@xxxxxxx
Precedence: bulk
X-list: linux-xfs

On Thu, 2003-02-27 at 09:49, Marc Schmitt wrote:
> Stephen Lord wrote:
> > On Thu, 2003-02-27 at 02:51, Marc Schmitt wrote:
> > 
> > Its really simple:
> > 
> > 	8 * 32K or 256K per filesystem that you use these options on.
> > 
> > Usually no problem unless memory is tight at the time of mount. These
> > options do not make sense unless that filesystem is under constant
> > heavy metadata load.
>
> Thanks for the answers, Seth and Steve. I'm not sure what you mean by 
> heavy metadata load, sorry. What produces such load? Databases? Home 
> directories of a whole bunch of users on the same partition?

A news or mail server would be a good one. A database does not
usually once it is setup.

> In an earlier post (Re: Best Logfile size for XFS; 02/11/2002), Steve wrote:
> > There is no hard and fast rule for this, a larger log is only really useful if you
> > are doing metadata intensive operations over extended periods of time and
> > we have found that more iclogs are just as useful (the logbugs=8 mount option).
> > I cannot remember right now, but mkfs may automatically make the
> > log bigger on large devices, of course large may be past the 2 Tbyte limit
> > on linux.
> > 
> > For write performance a larger log will not help, more iclogs might, but
> > not by much.
> > 
> > The other thing to consider with larger logs is that recovery after a crash
> > can take longer.
>
> Logbufs are in memory only, right? If yes, the more I have, the more 
> information gets lost on a crash, the higher the chance of heavy 
> filesystem corruption, correct?

Not of corruption, but if the amount time can roll backwards after
recovery. Even at this size though, we probably have less data
in flight than ext3 or reiserfs, not sure about jfs. What it
does also mean is mounts after a crash will take longer.

Steve

--

Steve Lord                                      voice: +1-651-683-3511
Principal Engineer, Filesystem Software         email: lord@xxxxxxx


rom owner-linux-xfs@xxxxxxxxxxx Thu Feb 27 10:47:28 2003
Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 27 Feb 2003 10:47:33 
-0800 (PST)
Received: from oss.sgi.com (localhost [127.0.0.1])
        by oss.sgi.com (8.12.5/8.12.5) with ESMTP id h1RIlReA008833
        for <linux-xfs@xxxxxxxxxxx>; Thu, 27 Feb 2003 10:47:27 -0800
Received: (from xfs@localhost)
        by oss.sgi.com (8.12.5/8.12.5/Submit) id h1RIlR96008832
        for linux-xfs@xxxxxxxxxxx; Thu, 27 Feb 2003 10:47:27 -0800
Received: from oss.sgi.com (localhost [127.0.0.1])
        by oss.sgi.com (8.12.5/8.12.5) with ESMTP id h1RIlPeA008816
        for <xfs-master@xxxxxxxxxxx>; Thu, 27 Feb 2003 10:47:25 -0800
Received: (from apache@localhost)
        by oss.sgi.com (8.12.5/8.12.5/Submit) id h1RIbKtb008589;
        Thu, 27 Feb 2003 10:37:20 -0800
Date: Thu, 27 Feb 2003 10:37:20 -0800
Message-Id: <200302271837.h1RIbKtb008589@xxxxxxxxxxx>
From: bugzilla-daemon@xxxxxxxxxxx
To: xfs-master@xxxxxxxxxxx
Subject: [Bug 225] thread deadlock on full fs.
X-Bugzilla-Reason: AssignedTo
X-archive-position: 2957
X-ecartis-version: Ecartis v1.0.0
Sender: linux-xfs-bounce@xxxxxxxxxxx
Errors-to: linux-xfs-bounce@xxxxxxxxxxx
X-original-sender: bugzilla-daemon@xxxxxxxxxxx
Precedence: bulk
X-list: linux-xfs

http://oss.sgi.com/bugzilla/show_bug.cgi?id=225

stephy32@xxxxxxxxxxxx changed:

          What    |Removed                     |Added
----------------------------------------------------------------------------
          Severity|critical                    |blocker





------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.


rom owner-linux-xfs@xxxxxxxxxxx Thu Feb 27 10:47:53 2003
Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 27 Feb 2003 10:47:58 
-0800 (PST)
Received: from tolkor.sgi.com (tolkor.sgi.com [198.149.18.6])
        by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1RIlqeA008914
        for <linux-xfs@xxxxxxxxxxx>; Thu, 27 Feb 2003 10:47:53 -0800
Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com 
[192.48.203.134])
        by tolkor.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP 
id h1RIvtkq013189
        for <linux-xfs@xxxxxxxxxxx>; Thu, 27 Feb 2003 12:57:55 -0600
Received: from thistle-e236.americas.sgi.com (thistle-e236.americas.sgi.com 
[128.162.236.204]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) 
with ESMTP id MAA75557 for <linux-xfs@xxxxxxxxxxx>; Thu, 27 Feb 2003 12:47:45 
-0600 (CST)
Received: from clink.americas.sgi.com (clink.americas.sgi.com [128.162.236.153]) by 
thistle-e236.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id MAA79590 for 
<linux-xfs@xxxxxxxxxxx>; Thu, 27 Feb 2003 12:47:45 -0600 (CST)
Received: from clink.americas.sgi.com (localhost [127.0.0.1])
        by clink.americas.sgi.com (SGI-8.12.5/8.12.5/erikj-IRIX6519-news) with 
ESMTP id h1RIlo0t5223509
        for <linux-xfs@xxxxxxxxxxx>; Thu, 27 Feb 2003 12:47:50 -0600 (CST)
Received: (from roehrich@localhost)
        by clink.americas.sgi.com (SGI-8.12.5/8.12.5/Submit) id h1RIln1N4595744
        for linux-xfs@xxxxxxxxxxx; Thu, 27 Feb 2003 12:47:49 -0600 (CST)
Date: Thu, 27 Feb 2003 12:47:49 -0600 (CST)
From: Dean Roehrich <roehrich@xxxxxxxxxxxxxxxxxxxxxx>
Message-Id: <200302271847.h1RIln1N4595744@xxxxxxxxxxxxxxxxxxxxxx>
To: linux-xfs@xxxxxxxxxxx
Subject: TAKE - POSTCREATE never fires
X-archive-position: 2958
X-ecartis-version: Ecartis v1.0.0
Sender: linux-xfs-bounce@xxxxxxxxxxx
Errors-to: linux-xfs-bounce@xxxxxxxxxxx
X-original-sender: roehrich@xxxxxxxxxxxxxxxxxxxxxx
Precedence: bulk
X-list: linux-xfs

fix dmapi POSTCREATE event in xfs_create/xfs_mkdir


Date:  Thu Feb 27 10:46:30 PST 2003
Workarea:  clink.americas.sgi.com:/data/clink/a67/roehrich/2.4.x-xfs

The following file(s) were checked into:
 bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs


Modid:  2.4.x-xfs:slinx:140501a
linux/fs/xfs/xfs_vnodeops.c - 1.583
        - Add dm_event_sent to xfs_create/xfs_mkdir.  Make POSTCREATE work the
          way it does in Irix.



rom owner-linux-xfs@xxxxxxxxxxx Thu Feb 27 11:13:58 2003
Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 27 Feb 2003 11:14:03 
-0800 (PST)
Received: from dea.linux-mips.net (p508B7BED.dip.t-dialin.net [80.139.123.237])
        by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1RJDueA011640
        for <linux-xfs@xxxxxxxxxxx>; Thu, 27 Feb 2003 11:13:57 -0800
Received: (from ralf@localhost)
        by dea.linux-mips.net (8.11.6/8.11.6) id h1RJDro16217
        for linux-xfs@xxxxxxxxxxx; Thu, 27 Feb 2003 20:13:53 +0100
Date: Thu, 27 Feb 2003 20:13:53 +0100
From: Ralf Baechle <ralf@xxxxxxxxxxxxxx>
To: linux-xfs@xxxxxxxxxxx
Subject: ADMIN: Test, please ignore ...
Message-ID: <20030227201353.A16049@xxxxxxxxxxxxxx>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5.1i
X-archive-position: 2959
X-ecartis-version: Ecartis v1.0.0
Sender: linux-xfs-bounce@xxxxxxxxxxx
Errors-to: linux-xfs-bounce@xxxxxxxxxxx
X-original-sender: ralf@xxxxxxxxxxxxxx
Precedence: bulk
X-list: linux-xfs

Sorry, the list is acting up ...


rom owner-linux-xfs@xxxxxxxxxxx Thu Feb 27 11:17:27 2003
Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 27 Feb 2003 11:17:32 
-0800 (PST)
Received: from oss.sgi.com (localhost [127.0.0.1])
        by oss.sgi.com (8.12.5/8.12.5) with ESMTP id h1RJHReA011833
        for <linux-xfs@xxxxxxxxxxx>; Thu, 27 Feb 2003 11:17:27 -0800
Received: (from xfs@localhost)
        by oss.sgi.com (8.12.5/8.12.5/Submit) id h1RJHRVd011829
        for linux-xfs@xxxxxxxxxxx; Thu, 27 Feb 2003 11:17:27 -0800
Received: from oss.sgi.com (localhost [127.0.0.1])
        by oss.sgi.com (8.12.5/8.12.5) with ESMTP id h1RJHPeC011813
        for <xfs-master@xxxxxxxxxxx>; Thu, 27 Feb 2003 11:17:25 -0800
Received: (from apache@localhost)
        by oss.sgi.com (8.12.5/8.12.5/Submit) id h1RIo5qu009391;
        Thu, 27 Feb 2003 10:50:05 -0800
Date: Thu, 27 Feb 2003 10:50:05 -0800
Message-Id: <200302271850.h1RIo5qu009391@xxxxxxxxxxx>
From: bugzilla-daemon@xxxxxxxxxxx
To: xfs-master@xxxxxxxxxxx
Subject: [Bug 220] POSTCREATE never fires
X-Bugzilla-Reason: AssignedTo
X-archive-position: 2960
X-ecartis-version: Ecartis v1.0.0
Sender: linux-xfs-bounce@xxxxxxxxxxx
Errors-to: linux-xfs-bounce@xxxxxxxxxxx
X-original-sender: bugzilla-daemon@xxxxxxxxxxx
Precedence: bulk
X-list: linux-xfs

http://oss.sgi.com/bugzilla/show_bug.cgi?id=220

roehrich@xxxxxxx changed:

          What    |Removed                     |Added
----------------------------------------------------------------------------
            Status|NEW                         |RESOLVED
        Resolution|                            |FIXED



------- Additional Comments From roehrich@xxxxxxx  2003-02-27 10:50 -------
Modid:  2.4.x-xfs:slinx:140501a
linux/fs/xfs/xfs_vnodeops.c - 1.583
       - Add dm_event_sent to xfs_create/xfs_mkdir.  Make POSTCREATE work the
         way it does in Irix.




------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.


rom owner-linux-xfs@xxxxxxxxxxx Thu Feb 27 11:25:48 2003
Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 27 Feb 2003 11:25:55 -0800 (PST)
Received: from ubergeek ([209.184.141.189])
	by oss.sgi.com (8.12.5/8.12.5) with SMTP id h1RJPleA012270
	for <linux-xfs@xxxxxxxxxxx>; Thu, 27 Feb 2003 11:25:48 -0800
Received: (qmail 15548 invoked by uid 500); 27 Feb 2003 19:23:16 -0000
Subject: Re: xattr manpages
From: Austin Gonyou <austin@xxxxxxxxxxxxxxx>
To: Andries.Brouwer@xxxxxx
Cc: a.gruenbacher@xxxxxxxxxxxx, ag@xxxxxxxxxxx, ak@xxxxxxx, kaos@xxxxxxxxxx,
  XFS List <linux-xfs@xxxxxxxxxxx>, lord@xxxxxxx
In-Reply-To: <UTC200302270037.h1R0bxr09281.aeb@xxxxxxxxxxx>
References: <UTC200302270037.h1R0bxr09281.aeb@xxxxxxxxxxx>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Organization: Coremetrics, Inc.
Message-Id: <1046373795.14894.19.camel@UberGeek>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.2.2 
Date: 27 Feb 2003 13:23:16 -0600
X-archive-position: 2961
X-ecartis-version: Ecartis v1.0.0
Sender: linux-xfs-bounce@xxxxxxxxxxx
Errors-to: linux-xfs-bounce@xxxxxxxxxxx
X-original-sender: austin@xxxxxxxxxxxxxxx
Precedence: bulk
X-list: linux-xfs

On Wed, 2003-02-26 at 18:37, Andries.Brouwer@xxxxxx wrote:
> Several new manpages have been contributed, so I was
> considering a new man-pages release for this weekend.
> Remains the question: what is the *xattr copyright situation today?


XFS still does not support "immutable" right?

> Andries
--
Austin Gonyou <austin@xxxxxxxxxxxxxxx>
Coremetrics, Inc.