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.
|