I''m doing some probing of this problem with debugfs now. However, I noticed another problem with file attributes while using chattr and lsattr under Lustre: # touch /mnt/lustre/a # ln /mnt/lustre/a /mnt/lustre/b # chattr +ASs /mnt/lustre/a # lsattr /mnt/lustre/a -------A----- a # lsattr /mnt/lustre/b -------A----- a Of course, lsattr should be returning: s-S----A----- a Very odd. xattr is only partially working. It doesn''t appear to be a hard-linking problem, however. On 6/3/06, Peter J. Braam <braam@clusterfs.com> wrote:> Hi, > > That''s a bit puzzling - how about taking a look with debugfs on the file > system that the MDS is using? > > That should reveal what is going on at the disk level. > > - Peter - > > > -----Original Message----- > > From: lustre-discuss-bounces@clusterfs.com > > [mailto:lustre-discuss-bounces@clusterfs.com] On Behalf Of EKC > > Sent: Saturday, June 03, 2006 3:49 PM > > To: lustre-discuss@clusterfs.com > > Subject: [Lustre-discuss] Does Lustre ext3 Support xattr? > > > > Hello: > > > > I know that lustre is using a modified version of ext3. > > However, does it fully support xattr? I''m having some > > problems using xattr on hard-linked files under a lustre filesystem. > > > > My MDS and OST nodes are running a lustre-1.4.6.2 patched mainline > > 2.6.12 vanilla kernel. In the kernel config file I''ve enabled > > the CONFIG_EXT3_FS_XATTR option. > > > > On the surface, when my lustre client sets xattr''s on a > > lustre-mounted file, those attributes seem to be set (I''m > > using setattr and showattr from the linux-vserver project). > > > > However, if I hard-link one file to another and set xattr''s > > on one of them (but not the other), the xattrs of the two > > files differ even though ''ls -i'' indicates that they both > > share the same inode. So: > > 1) touch /mnt/lustre/a > > 2) ln /mnt/lustre/a /mnt/lustre/b # ''ls -i'' reports that they both > > share the same i-node > > 3) setattr --iunlink /mnt/lustre/a > > 4) showattr /mnt/lustre/a > > # ----UI- a > > 5) showattr /mnt/lustre/b > > # ----ui- b > > > > So, even though both a and b share the same i-node, they have > > different xattr''s. How is this possible? It seems to me that > > either the lustre OST does not support xattr''s correctly or > > that there''s some indirection/abstraction going on with the > > hardlinks. Do files ''a'' > > and ''b'' really share the same i-node, as ls reports? > > > > Oddly enough, if I write to the contents of file b, those > > changes are reflected in a. So, it seems that hardlinks are > > being handled to some degree. > > > > Is there some sort of patch that I can apply to the lustre > > OSS/MDS to enable xattr support? > > > > The reason I need xattr support, is that I want my lustre > > cluster to support copy-on-write. I''ve patched my lustre clients > > (1.4.6-patchless) with the copy-on-write and > > bind-mount-extension patches from linux-vserver > > (http://vserver.13thfloor.at/Experimental/del-2.6.16-rc1-vs2.1 > > .0.9/37_cow.diff) > > and > > (http://vserver.13thfloor.at/Experimental/del-2.6.16-rc1-vs2.1 > > .0.9/36_bme.diff). > > COW is implemented by the lustre-client kernel, and it''s > > working fine (as are xattr''s) on a locally mounted ext3 > > harddisk on the lustre clients. Which is why I''m curious > > about how the lustre OSS and OST''s handle xattr. > > > > Thanks in advance for your help, > > > > Eser > > _______________________________________________ > > Lustre-discuss mailing list > > Lustre-discuss@clusterfs.com > > https://mail.clusterfs.com/mailman/listinfo/lustre-discuss > > > > > >
Hi, That''s a bit puzzling - how about taking a look with debugfs on the file system that the MDS is using? That should reveal what is going on at the disk level. - Peter -> -----Original Message----- > From: lustre-discuss-bounces@clusterfs.com > [mailto:lustre-discuss-bounces@clusterfs.com] On Behalf Of EKC > Sent: Saturday, June 03, 2006 3:49 PM > To: lustre-discuss@clusterfs.com > Subject: [Lustre-discuss] Does Lustre ext3 Support xattr? > > Hello: > > I know that lustre is using a modified version of ext3. > However, does it fully support xattr? I''m having some > problems using xattr on hard-linked files under a lustre filesystem. > > My MDS and OST nodes are running a lustre-1.4.6.2 patched mainline > 2.6.12 vanilla kernel. In the kernel config file I''ve enabled > the CONFIG_EXT3_FS_XATTR option. > > On the surface, when my lustre client sets xattr''s on a > lustre-mounted file, those attributes seem to be set (I''m > using setattr and showattr from the linux-vserver project). > > However, if I hard-link one file to another and set xattr''s > on one of them (but not the other), the xattrs of the two > files differ even though ''ls -i'' indicates that they both > share the same inode. So: > 1) touch /mnt/lustre/a > 2) ln /mnt/lustre/a /mnt/lustre/b # ''ls -i'' reports that they both > share the same i-node > 3) setattr --iunlink /mnt/lustre/a > 4) showattr /mnt/lustre/a > # ----UI- a > 5) showattr /mnt/lustre/b > # ----ui- b > > So, even though both a and b share the same i-node, they have > different xattr''s. How is this possible? It seems to me that > either the lustre OST does not support xattr''s correctly or > that there''s some indirection/abstraction going on with the > hardlinks. Do files ''a'' > and ''b'' really share the same i-node, as ls reports? > > Oddly enough, if I write to the contents of file b, those > changes are reflected in a. So, it seems that hardlinks are > being handled to some degree. > > Is there some sort of patch that I can apply to the lustre > OSS/MDS to enable xattr support? > > The reason I need xattr support, is that I want my lustre > cluster to support copy-on-write. I''ve patched my lustre clients > (1.4.6-patchless) with the copy-on-write and > bind-mount-extension patches from linux-vserver > (http://vserver.13thfloor.at/Experimental/del-2.6.16-rc1-vs2.1 > .0.9/37_cow.diff) > and > (http://vserver.13thfloor.at/Experimental/del-2.6.16-rc1-vs2.1 > .0.9/36_bme.diff). > COW is implemented by the lustre-client kernel, and it''s > working fine (as are xattr''s) on a locally mounted ext3 > harddisk on the lustre clients. Which is why I''m curious > about how the lustre OSS and OST''s handle xattr. > > Thanks in advance for your help, > > Eser > _______________________________________________ > Lustre-discuss mailing list > Lustre-discuss@clusterfs.com > https://mail.clusterfs.com/mailman/listinfo/lustre-discuss > >
Hello: I know that lustre is using a modified version of ext3. However, does it fully support xattr? I''m having some problems using xattr on hard-linked files under a lustre filesystem. My MDS and OST nodes are running a lustre-1.4.6.2 patched mainline 2.6.12 vanilla kernel. In the kernel config file I''ve enabled the CONFIG_EXT3_FS_XATTR option. On the surface, when my lustre client sets xattr''s on a lustre-mounted file, those attributes seem to be set (I''m using setattr and showattr from the linux-vserver project). However, if I hard-link one file to another and set xattr''s on one of them (but not the other), the xattrs of the two files differ even though ''ls -i'' indicates that they both share the same inode. So: 1) touch /mnt/lustre/a 2) ln /mnt/lustre/a /mnt/lustre/b # ''ls -i'' reports that they both share the same i-node 3) setattr --iunlink /mnt/lustre/a 4) showattr /mnt/lustre/a # ----UI- a 5) showattr /mnt/lustre/b # ----ui- b So, even though both a and b share the same i-node, they have different xattr''s. How is this possible? It seems to me that either the lustre OST does not support xattr''s correctly or that there''s some indirection/abstraction going on with the hardlinks. Do files ''a'' and ''b'' really share the same i-node, as ls reports? Oddly enough, if I write to the contents of file b, those changes are reflected in a. So, it seems that hardlinks are being handled to some degree. Is there some sort of patch that I can apply to the lustre OSS/MDS to enable xattr support? The reason I need xattr support, is that I want my lustre cluster to support copy-on-write. I''ve patched my lustre clients (1.4.6-patchless) with the copy-on-write and bind-mount-extension patches from linux-vserver (http://vserver.13thfloor.at/Experimental/del-2.6.16-rc1-vs2.1.0.9/37_cow.diff) and (http://vserver.13thfloor.at/Experimental/del-2.6.16-rc1-vs2.1.0.9/36_bme.diff). COW is implemented by the lustre-client kernel, and it''s working fine (as are xattr''s) on a locally mounted ext3 harddisk on the lustre clients. Which is why I''m curious about how the lustre OSS and OST''s handle xattr. Thanks in advance for your help, Eser
Hi Eser, There is plenty here to file a bug I think, both the behavior below and the hardlink example from yesterday are wrong. Could you file that bug at http://bugzilla.clusterfs.com please? The setattr output is probably OK - Lustre uses a setattr RPC to the server even to set extended attributes. Thanks! - Peter -> -----Original Message----- > From: lustre-discuss-bounces@clusterfs.com > [mailto:lustre-discuss-bounces@clusterfs.com] On Behalf Of EKC > Sent: Sunday, June 04, 2006 7:04 AM > To: lustre-discuss@clusterfs.com > Subject: Re: [Lustre-discuss] Does Lustre ext3 Support xattr? > > It appears that this is a Lustre xattr issue that affects the > production release: > > It seems that there may be bug (still trying to narrow it > down) in the mds/llite code that prevents lustre from fully > supporting xattr. I''m not sure if there is something > anomalous in my configuration, or if this behavior reflects a > bug (safety feature?) in Lustre''s xattr support. I''ve played > around with the xattr filter code in llite/xattr.c to no > avail. Can anyone reproduce the behavior described below? > > I''ve setup my environment so that my clients, MDS, and OST''s > are all running the same version of lustre: 1.4.6.2 > (non-patchless) production release on a plain vanilla 2.6.12 > mainline kernel. The only other patch applied to the kernel is DRBD. > > Here is the behavior of chattr and lsattr on my lustre cluster: > ===test#1==> # touch /mnt/lustre/a > # chattr +iu /mnt/lustre/a > # lsattr /mnt/lustre/a > ----i-------- a > That should be: > -u--i-------- a > > ===test#2==> # touch /mnt/lustre/b > # chattr +Ss /mnt/lustre/b > # lsattr /mnt/lustre/b > ------------- b > That should be: > s-S---------- b > > Several other permutations of chattr/lsattr fail as well. > > lctl''s debug_daemon is reporting that setattr (not setxattr) > operations are being called. I haven''t been able to parse the > log file yet to determine exactly which flags (if any) are > being passed around. > > Is Lustre trying to sanitize/filter the setxattr commands > (for flags it doesn''t yet implement)? If so, where should I > look to disable this functionality? > > Thanks again, > Eser > > > > On 6/3/06, Peter J. Braam <braam@clusterfs.com> wrote: > > Hi, > > > > That''s a bit puzzling - how about taking a look with debugfs on the > > file system that the MDS is using? > > > > That should reveal what is going on at the disk level. > > > > - Peter - > > > > > -----Original Message----- > > > From: lustre-discuss-bounces@clusterfs.com > > > [mailto:lustre-discuss-bounces@clusterfs.com] On Behalf Of EKC > > > Sent: Saturday, June 03, 2006 3:49 PM > > > To: lustre-discuss@clusterfs.com > > > Subject: [Lustre-discuss] Does Lustre ext3 Support xattr? > > > > > > Hello: > > > > > > I know that lustre is using a modified version of ext3. > > > However, does it fully support xattr? I''m having some > problems using > > > xattr on hard-linked files under a lustre filesystem. > > > > > > My MDS and OST nodes are running a lustre-1.4.6.2 patched mainline > > > 2.6.12 vanilla kernel. In the kernel config file I''ve enabled the > > > CONFIG_EXT3_FS_XATTR option. > > > > > > On the surface, when my lustre client sets xattr''s on a > > > lustre-mounted file, those attributes seem to be set (I''m using > > > setattr and showattr from the linux-vserver project). > > > > > > However, if I hard-link one file to another and set > xattr''s on one > > > of them (but not the other), the xattrs of the two files > differ even > > > though ''ls -i'' indicates that they both share the same inode. So: > > > 1) touch /mnt/lustre/a > > > 2) ln /mnt/lustre/a /mnt/lustre/b # ''ls -i'' reports > that they both > > > share the same i-node > > > 3) setattr --iunlink /mnt/lustre/a > > > 4) showattr /mnt/lustre/a > > > # ----UI- a > > > 5) showattr /mnt/lustre/b > > > # ----ui- b > > > > > > So, even though both a and b share the same i-node, they have > > > different xattr''s. How is this possible? It seems to me > that either > > > the lustre OST does not support xattr''s correctly or that > there''s > > > some indirection/abstraction going on with the hardlinks. > Do files > > > ''a'' > > > and ''b'' really share the same i-node, as ls reports? > > > > > > Oddly enough, if I write to the contents of file b, those changes > > > are reflected in a. So, it seems that hardlinks are being > handled to > > > some degree. > > > > > > Is there some sort of patch that I can apply to the > lustre OSS/MDS > > > to enable xattr support? > > > > > > The reason I need xattr support, is that I want my lustre > cluster to > > > support copy-on-write. I''ve patched my lustre clients > > > (1.4.6-patchless) with the copy-on-write and bind-mount-extension > > > patches from linux-vserver > > > (http://vserver.13thfloor.at/Experimental/del-2.6.16-rc1-vs2.1 > > > .0.9/37_cow.diff) > > > and > > > (http://vserver.13thfloor.at/Experimental/del-2.6.16-rc1-vs2.1 > > > .0.9/36_bme.diff). > > > COW is implemented by the lustre-client kernel, and it''s working > > > fine (as are xattr''s) on a locally mounted ext3 harddisk on the > > > lustre clients. Which is why I''m curious about how the lustre OSS > > > and OST''s handle xattr. > > > > > > Thanks in advance for your help, > > > > > > Eser > > > _______________________________________________ > > > Lustre-discuss mailing list > > > Lustre-discuss@clusterfs.com > > > https://mail.clusterfs.com/mailman/listinfo/lustre-discuss > > > > > > > > > > > _______________________________________________ > Lustre-discuss mailing list > Lustre-discuss@clusterfs.com > https://mail.clusterfs.com/mailman/listinfo/lustre-discuss > >
On Jun 03, 2006 15:49 -0600, EKC wrote:> I know that lustre is using a modified version of ext3. However, does > it fully support xattr? I''m having some problems using xattr on > hard-linked files under a lustre filesystem.I think you are confusing the term "xattr" (not that there isn''t a lot to be confused about, as you will read below ;-). "xattr" is normally used to refer to "extended attributes", which are "name=value" pairs stored on the inode. Support for this was added to the 1.4.6 release, if the client and MDS are mounted with "-o user_xattr". These are used in conjunction with the "getfattr" and "setfattr" utilities. What you are referring to in your email are "file attributes", used in conjunction with the "chattr" and "lsattr" tools. These are flags set on the inode to give it special behaviour when accessed by the filesystem, such as "immutable" or "append only". The only file attributes that Lustre supports in the 1.4.6 release are the "immutable" and "append-only" flags. In the upcoming 1.4.7 release it will support more flags (as many as ext3 currently also supports) with the exception of "data journal" (j) mode. This means that while you might be able to set a lot of flags on the inode such as "secure deletion" or "undelete" that doesn''t mean these flags will actually do anything useful: chattr(1): BUGS AND LIMITATIONS The ?c?, ?s?, and ?u? attributes are not honored by the ext2 and ext3 filesystems as implemented in the current mainline Linux kernels. These attributes may be implemented in future versions of the ext2 and ext3 filesystems.> My MDS and OST nodes are running a lustre-1.4.6.2 patched mainline > 2.6.12 vanilla kernel. In the kernel config file I''ve enabled the > CONFIG_EXT3_FS_XATTR option.This is completely unrelated to "file attributes", but rather related to "extended attributes".> On the surface, when my lustre client sets xattr''s on a lustre-mounted > file, those attributes seem to be set (I''m using setattr and showattr > from the linux-vserver project).The preferred tools are "lsattr" and "chattr", which are in every version of e2fsprogs since time immemorial, and are updated to reflect the most current flags that are defined for ext2.> However, if I hard-link one file to another and set xattr''s on one of > them (but not the other), the xattrs of the two files differ even > though ''ls -i'' indicates that they both share the same inode. So: > 1) touch /mnt/lustre/a > 2) ln /mnt/lustre/a /mnt/lustre/b # ''ls -i'' reports that they both > share the same i-node > 3) setattr --iunlink /mnt/lustre/a > 4) showattr /mnt/lustre/a > # ----UI- a > 5) showattr /mnt/lustre/b > # ----ui- bThere is no "U" flag defined for ext2 (according to the chattr(1) man page).> The reason I need xattr support, is that I want my lustre cluster to > support copy-on-write. I''ve patched my lustre clients > (1.4.6-patchless) with the copy-on-write and bind-mount-extension > patches from linux-vserver > (http://vserver.13thfloor.at/Experimental/del-2.6.16-rc1-vs2.1.0.9/37_cow.diff) > and > (http://vserver.13thfloor.at/Experimental/del-2.6.16-rc1-vs2.1.0.9/36_bme.diff). > COW is implemented by the lustre-client kernel, and it''s working fine > (as are xattr''s) on a locally mounted ext3 harddisk on the lustre > clients. Which is why I''m curious about how the lustre OSS and OST''s > handle xattr.As to what this COW patch is doing under the covers, there is a huge gulf between what a local ext3 filesystem mount is doing and what a Lustre client mount is doing. The fact that this is working on a local ext3 mount doesn''t mean that it will work at all correctly with a Lustre mount, because the COW code is probably not integrating with the Lustre DLM locking, or many other aspects of how Lustre is behaving on the client. I don''t want to discourage you from trying this out, but rather to clarify that since the COW code was probably developed and tested to work with ext3 doesn''t mean it will work with Lustre. Cheers, Andreas -- Andreas Dilger Principal Software Engineer Cluster File Systems, Inc.
It appears that this is a Lustre xattr issue that affects the production release: It seems that there may be bug (still trying to narrow it down) in the mds/llite code that prevents lustre from fully supporting xattr. I''m not sure if there is something anomalous in my configuration, or if this behavior reflects a bug (safety feature?) in Lustre''s xattr support. I''ve played around with the xattr filter code in llite/xattr.c to no avail. Can anyone reproduce the behavior described below? I''ve setup my environment so that my clients, MDS, and OST''s are all running the same version of lustre: 1.4.6.2 (non-patchless) production release on a plain vanilla 2.6.12 mainline kernel. The only other patch applied to the kernel is DRBD. Here is the behavior of chattr and lsattr on my lustre cluster: ===test#1==# touch /mnt/lustre/a # chattr +iu /mnt/lustre/a # lsattr /mnt/lustre/a ----i-------- a That should be: -u--i-------- a ===test#2==# touch /mnt/lustre/b # chattr +Ss /mnt/lustre/b # lsattr /mnt/lustre/b ------------- b That should be: s-S---------- b Several other permutations of chattr/lsattr fail as well. lctl''s debug_daemon is reporting that setattr (not setxattr) operations are being called. I haven''t been able to parse the log file yet to determine exactly which flags (if any) are being passed around. Is Lustre trying to sanitize/filter the setxattr commands (for flags it doesn''t yet implement)? If so, where should I look to disable this functionality? Thanks again, Eser On 6/3/06, Peter J. Braam <braam@clusterfs.com> wrote:> Hi, > > That''s a bit puzzling - how about taking a look with debugfs on the file > system that the MDS is using? > > That should reveal what is going on at the disk level. > > - Peter - > > > -----Original Message----- > > From: lustre-discuss-bounces@clusterfs.com > > [mailto:lustre-discuss-bounces@clusterfs.com] On Behalf Of EKC > > Sent: Saturday, June 03, 2006 3:49 PM > > To: lustre-discuss@clusterfs.com > > Subject: [Lustre-discuss] Does Lustre ext3 Support xattr? > > > > Hello: > > > > I know that lustre is using a modified version of ext3. > > However, does it fully support xattr? I''m having some > > problems using xattr on hard-linked files under a lustre filesystem. > > > > My MDS and OST nodes are running a lustre-1.4.6.2 patched mainline > > 2.6.12 vanilla kernel. In the kernel config file I''ve enabled > > the CONFIG_EXT3_FS_XATTR option. > > > > On the surface, when my lustre client sets xattr''s on a > > lustre-mounted file, those attributes seem to be set (I''m > > using setattr and showattr from the linux-vserver project). > > > > However, if I hard-link one file to another and set xattr''s > > on one of them (but not the other), the xattrs of the two > > files differ even though ''ls -i'' indicates that they both > > share the same inode. So: > > 1) touch /mnt/lustre/a > > 2) ln /mnt/lustre/a /mnt/lustre/b # ''ls -i'' reports that they both > > share the same i-node > > 3) setattr --iunlink /mnt/lustre/a > > 4) showattr /mnt/lustre/a > > # ----UI- a > > 5) showattr /mnt/lustre/b > > # ----ui- b > > > > So, even though both a and b share the same i-node, they have > > different xattr''s. How is this possible? It seems to me that > > either the lustre OST does not support xattr''s correctly or > > that there''s some indirection/abstraction going on with the > > hardlinks. Do files ''a'' > > and ''b'' really share the same i-node, as ls reports? > > > > Oddly enough, if I write to the contents of file b, those > > changes are reflected in a. So, it seems that hardlinks are > > being handled to some degree. > > > > Is there some sort of patch that I can apply to the lustre > > OSS/MDS to enable xattr support? > > > > The reason I need xattr support, is that I want my lustre > > cluster to support copy-on-write. I''ve patched my lustre clients > > (1.4.6-patchless) with the copy-on-write and > > bind-mount-extension patches from linux-vserver > > (http://vserver.13thfloor.at/Experimental/del-2.6.16-rc1-vs2.1 > > .0.9/37_cow.diff) > > and > > (http://vserver.13thfloor.at/Experimental/del-2.6.16-rc1-vs2.1 > > .0.9/36_bme.diff). > > COW is implemented by the lustre-client kernel, and it''s > > working fine (as are xattr''s) on a locally mounted ext3 > > harddisk on the lustre clients. Which is why I''m curious > > about how the lustre OSS and OST''s handle xattr. > > > > Thanks in advance for your help, > > > > Eser > > _______________________________________________ > > Lustre-discuss mailing list > > Lustre-discuss@clusterfs.com > > https://mail.clusterfs.com/mailman/listinfo/lustre-discuss > > > > > >
Thank you for clarifying this whole xattr/file-attributes matter for me. I''ve got COW working under NFS and a RedHat GFS cluster that I''ve setup. However, I would very much like to use Lustre instead. I''m upgrading to Lustre 1.4.7beta2 right now to see if it allows me to set the file attribute tags that I need. I''ve also successfully patched BME into lustre by disabling some of the ro bind-mount-extension functionality that I don''t need. The VFS interface changes made by BME required some fairly minor tweaks to lustre. I''m running tests to confirm that I didn''t break anything. So far, it looks good. I understand that I may be breaking forward compatibility if I start setting unsupported file attribute tags. So, it makes sense that Lustre is dropping unsupported file attribute flags that I pass to ioctl. However, I need to change this behavior -- I need to be able to set arbitrary file attribute flags. There must be some filtering code that mds/llite uses to parse and validate the file attribute tags that I pass to ioctl. I can''t figure out where lustre is dropping my flags. Where does lustre parse/validate the file system attributes passed to ioctl? Is this part of the kernel patches, llite, or MDS? What source file and/or subroutine do I need to modify to change this behavior? thanks again, eser On 6/5/06, Andreas Dilger <adilger@clusterfs.com> wrote:> On Jun 03, 2006 22:43 -0700, EKC wrote: > > I''m doing some probing of this problem with debugfs now. However, I > > noticed another problem with file attributes while using chattr and > > lsattr under Lustre: > > > > # touch /mnt/lustre/a > > # ln /mnt/lustre/a /mnt/lustre/b > > # chattr +ASs /mnt/lustre/a > > # lsattr /mnt/lustre/a > > -------A----- a > > # lsattr /mnt/lustre/b > > -------A----- a > > > > Of course, lsattr should be returning: > > s-S----A----- a > > Only "immutable" and "append-only" are in 1.4.6. Please try again with > 1.4.7 beta2, which should be available soon, if it isn''t already. > > Cheers, Andreas > -- > Andreas Dilger > Principal Software Engineer > Cluster File Systems, Inc. > >
On Jun 03, 2006 22:43 -0700, EKC wrote:> I''m doing some probing of this problem with debugfs now. However, I > noticed another problem with file attributes while using chattr and > lsattr under Lustre: > > # touch /mnt/lustre/a > # ln /mnt/lustre/a /mnt/lustre/b > # chattr +ASs /mnt/lustre/a > # lsattr /mnt/lustre/a > -------A----- a > # lsattr /mnt/lustre/b > -------A----- a > > Of course, lsattr should be returning: > s-S----A----- aOnly "immutable" and "append-only" are in 1.4.6. Please try again with 1.4.7 beta2, which should be available soon, if it isn''t already. Cheers, Andreas -- Andreas Dilger Principal Software Engineer Cluster File Systems, Inc.
On Jun 05, 2006 05:40 -0600, EKC wrote:> I''ve got COW working under NFS and a RedHat GFS cluster that I''ve > setup. However, I would very much like to use Lustre instead. I''m > upgrading to Lustre 1.4.7beta2 right now to see if it allows me to set > the file attribute tags that I need. > > Where does lustre parse/validate the file system attributes passed to > ioctl? Is this part of the kernel patches, llite, or MDS? What source > file and/or subroutine do I need to modify to change this behavior?This should be fixed if you have a 1.4.7 client and 1.4.7 MDS. Cheers, Andreas -- Andreas Dilger Principal Software Engineer Cluster File Systems, Inc.