[RFC] ioctl vs xattr for the filesystem specific attributes

[RFC] ioctl vs xattr for the filesystem specific attributes

[OGAWA Hirofumi]

Hi,

Bastien Roucaries <roucariesbastien@yahoo.fr> writes:

> This patch implement an "extended attributes" (XATTR) hook in aim to read or
> modify specific  fatfs flags' like ARCHIVE or SYSTEM.
> 
> I believe it's a good idea  because :
> 	- PAX ( GNU replacement of tar) save and restore XATTRs, so you can make more
> exact save of FATfs without use of specific programs.
> 	- It's an elegant means to avoid use of mattrib.
> 	- Samba can use this .
> but CONS :
> 	- use 2 Kb of kernel memory.

Bastien Roucaries <roucariesbastien@yahoo.fr> writes:

> Indeed some flags are shared by many namespace for instance immutable is 
> shared by xfs,ext2/3,jfs and by the fat ( with a special mount option). 
> Compress also is a very common flag
> This flags are in the "common" sub-namespace.
> 
> But some are fs specifics for instance notail attr of reiserfs,shortname of 
> fat.They are in the the "spec"sub-namespace

I received the above email.

This read/modify the file attributes of filesystem specific via xattr
interface (in this case, ARCHIVE, SYSTEM, HIDDEN flags of fatfs).

Yes, also we can provide it via ioctl like ext2/ext3 does now.

But if those flags provides by xattr interfaces and via one namespace
prefix, I guess the app can save/restore easy without dependency of
one fs.

Which interface would we use for attributes of filesystem specific?
Also if we use xattr, what namepace prefix should be used?

Any idea?

Thanks.

-- 
OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>

Re: [RFC] ioctl vs xattr for the filesystem specific attributes

[Rob North]

OGAWA Hirofumi wrote:
> Hi,
> 
> Bastien Roucaries <roucariesbastien@yahoo.fr> writes:
> 
> 
>>This patch implement an "extended attributes" (XATTR) hook in aim to read or
>>modify specific  fatfs flags' like ARCHIVE or SYSTEM.
>>
>>I believe it's a good idea  because :
>>	- PAX ( GNU replacement of tar) save and restore XATTRs, so you can make more
>>exact save of FATfs without use of specific programs.
>>	- It's an elegant means to avoid use of mattrib.
>>	- Samba can use this .
>>but CONS :
>>	- use 2 Kb of kernel memory.
> 
> 
> Bastien Roucaries <roucariesbastien@yahoo.fr> writes:
> 
> 
>>Indeed some flags are shared by many namespace for instance immutable is 
>>shared by xfs,ext2/3,jfs and by the fat ( with a special mount option). 
>>Compress also is a very common flag
>>This flags are in the "common" sub-namespace.
>>
>>But some are fs specifics for instance notail attr of reiserfs,shortname of 
>>fat.They are in the the "spec"sub-namespace
> 
> 
> I received the above email.
> 
> This read/modify the file attributes of filesystem specific via xattr
> interface (in this case, ARCHIVE, SYSTEM, HIDDEN flags of fatfs).
> 
> Yes, also we can provide it via ioctl like ext2/ext3 does now.
> 
> But if those flags provides by xattr interfaces and via one namespace
> prefix, I guess the app can save/restore easy without dependency of
> one fs.
> 
> Which interface would we use for attributes of filesystem specific?
> Also if we use xattr, what namepace prefix should be used?
> 
> Any idea?
> 
> Thanks.
> 


I like the ideas that the patch seems to propose.
Infact I'd like to see the use of xattr used for non-standard attributes
applied to all fs.
Specifically, I want to backup all partitions, and attribs from one OS:
Linux. I do not want to loose fat attributes during backup.
This would also be useful for the Wine developers.


If you haven't got a response to your questions, maybe make your own 
decisions and submit a patch anyway.


One question:
How does the patch deal with the fact that only some named xattrs are
permitted?

I see 2 options:
1. all files/dirs in fat mount posess fat-specific xattrs. These xattrs 
are initialised at file/dir create. No further attribs can be added, 
none can be deleted. the fat attribute's Boolean value is defined by 
extended attribute's value.
2. all fat-specific attribs are optional, absence/presence defines
boolean value. All operations are permitted, but can only add the
fat-specific attributes.

I prefer option 1, as it makes clear what attributes are available.

Re: [RFC] ioctl vs xattr for the filesystem specific attributes

[jw schultz]

On Sun, Aug 17, 2003 at 07:14:28PM +0100, Rob North wrote:
> OGAWA Hirofumi wrote:
> >Hi,
> >
> >Bastien Roucaries <roucariesbastien@yahoo.fr> writes:
> >
> >
> >>This patch implement an "extended attributes" (XATTR) hook in aim to read 
> >>or
> >>modify specific  fatfs flags' like ARCHIVE or SYSTEM.
> >>
> >>I believe it's a good idea  because :
> >>	- PAX ( GNU replacement of tar) save and restore XATTRs, so you can 
> >>	make more
> >>exact save of FATfs without use of specific programs.
> >>	- It's an elegant means to avoid use of mattrib.
> >>	- Samba can use this .
> >>but CONS :
> >>	- use 2 Kb of kernel memory.
> >
> >
> >Bastien Roucaries <roucariesbastien@yahoo.fr> writes:
> >
> >
> >>Indeed some flags are shared by many namespace for instance immutable is 
> >>shared by xfs,ext2/3,jfs and by the fat ( with a special mount option). 
> >>Compress also is a very common flag
> >>This flags are in the "common" sub-namespace.
> >>
> >>But some are fs specifics for instance notail attr of reiserfs,shortname 
> >>of fat.They are in the the "spec"sub-namespace
> >
> >
> >I received the above email.
> >
> >This read/modify the file attributes of filesystem specific via xattr
> >interface (in this case, ARCHIVE, SYSTEM, HIDDEN flags of fatfs).
> >
> >Yes, also we can provide it via ioctl like ext2/ext3 does now.
> >
> >But if those flags provides by xattr interfaces and via one namespace
> >prefix, I guess the app can save/restore easy without dependency of
> >one fs.
> >
> >Which interface would we use for attributes of filesystem specific?
> >Also if we use xattr, what namepace prefix should be used?
> >
> >Any idea?
> >
> >Thanks.
> >

I suggested something like this to Andreas Gruenbacher in
March.  We dialoged briefly about it and I've heard nothing
since.

> I like the ideas that the patch seems to propose.
> Infact I'd like to see the use of xattr used for non-standard attributes
> applied to all fs.
> Specifically, I want to backup all partitions, and attribs from one OS:
> Linux. I do not want to loose fat attributes during backup.
> This would also be useful for the Wine developers.
> 
> 
> If you haven't got a response to your questions, maybe make your own 
> decisions and submit a patch anyway.
> 
> 
> One question:
> How does the patch deal with the fact that only some named xattrs are
> permitted?
> 
> I see 2 options:
> 1. all files/dirs in fat mount posess fat-specific xattrs. These xattrs 
> are initialised at file/dir create. No further attribs can be added, 
> none can be deleted. the fat attribute's Boolean value is defined by 
> extended attribute's value.
> 2. all fat-specific attribs are optional, absence/presence defines
> boolean value. All operations are permitted, but can only add the
> fat-specific attributes.
> 
> I prefer option 1, as it makes clear what attributes are available.

My suggested approach was to only read and write the
attributes as a complete set.  Modification would require a
read, modify what is read, write.  The EA name i suggested
was system.file-attr.  Unsupported attributes would be
silently ignored (no error).  If you wished to save unsupported
attributes for use in a foreign filesystem they could be
preserved in a user.* attribute.

The primary purpose of my suggestion was backups and file
transfers but this could easily be built on to make a
chattr/mattrib type utility that is filesystem agnostic.

The following is extracted from my portions of the exchange.

| It occurred to me that it might be desirable to added a
| facility to the extended attributes to allow reading and
| setting (as a block) the ext2 file attributes.
| 
| I'm referring to the file attributes mentioned in the chattr
| command.
| 
| Adding this facility would allow saving and restoring of
| these attributes with utilities not having specific ext[23]
| support.
| 
| I'd suggest using long attribute names consistent with mount
| options with comma delimiters.  I'd suggest the names:
| 	noatime
| 	append
| 	compress
| 	nodump
| 	immutable|readonly
| 	journal
| 	zero|scrub
| 	sync
| 	notail
| 	undelete

To this you could add archive, system and hidden for FAT.

| The extended attribute might look like
| 	system.file-attr: noatime,notail
| 	
| It might be reasonable to discuss this with the other
| filesystem groups so that a common set of attribute names
| could be agreed upon.  Unrecognized attributes would be
| silently ignored.

| i wasn't suggesting that. [referring to [no]option to set/unset
| attributes]  When i suggested notail
| and noatime options i was just aligning it with the mount
| options to which the attribute bits matched.  The flag tail
| would not exist or would be the same as as notail.  I wasn't
| suggesting that
| 	setfattr -n system.file-attr -v notail,append myfile
| would modify the flags but that it
| would replace the file attributes of myfile like
| 	chattr =ta myfile
|
| Attributes not listed in a setfattr call would be cleared.
| 
| It would be something like (borrowed from ext2/super.c:parse_options)
| 
| 	__u32 flags = 0;
|         for (this_char = strtok (options, ",");
|              this_char != NULL;
|              this_char = strtok (NULL, ",")) {
| 		if (!strcmp (this_char, "noatime"))
| 			flags |= EXT2_NOATIME_FL;
| 		else if (!strcmp (this_char, "append"))
| 			flags |= EXT2_APPEND_FL;
| 		else if (!strcmp (this_char, "compress"))
| 			flags |= EXT2_COMPR_FL;
| 		else if (!strcmp (this_char, "nodump"))
| 			flags |= EXT2_NODUMP_FL;
| 		else if (!strcmp (this_char, "readonly")
| 		      || !strcmp (this_char, "immutable"))
| 			flags |= EXT2_immutable_FL;
| 		else if (!strcmp (this_char, "scrub"))
| 			flags |= EXT2_SECRM_FL;
| 		else if (!strcmp (this_char, "undelete"))
| 			flags |= EXT2_UNRM_FL;
| 		else if (!strcmp (this_char, "sync"))
| 			flags |= EXT2_SYNC_FL;
| 		else if (!strcmp (this_char, "undelete"))
| 			flags |= EXT2_UNRM_FL;
| 	}
| 	inode->i_flags = flags;
| 
| outputting the flag set would be much easier.
                        

-- 
________________________________________________________________
	J.W. Schultz            Pegasystems Technologies
	email address:		jw@pegasys.ws

		Remember Cernan and Schmitt


-- 
________________________________________________________________
	J.W. Schultz            Pegasystems Technologies
	email address:		jw@pegasys.ws

		Remember Cernan and Schmitt

Re: [RFC] ioctl vs xattr for the filesystem specific attributes

[OGAWA Hirofumi]

jw schultz <jw@pegasys.ws> writes:

> > >This read/modify the file attributes of filesystem specific via xattr
> > >interface (in this case, ARCHIVE, SYSTEM, HIDDEN flags of fatfs).
> > >
> > >Yes, also we can provide it via ioctl like ext2/ext3 does now.
> > >
> > >But if those flags provides by xattr interfaces and via one namespace
> > >prefix, I guess the app can save/restore easy without dependency of
> > >one fs.
> > >
> > >Which interface would we use for attributes of filesystem specific?
> > >Also if we use xattr, what namepace prefix should be used?
> > >
> > >Any idea?

> I suggested something like this to Andreas Gruenbacher in
> March.  We dialoged briefly about it and I've heard nothing
> since.

> > I like the ideas that the patch seems to propose.
> > Infact I'd like to see the use of xattr used for non-standard attributes
> > applied to all fs.
> > Specifically, I want to backup all partitions, and attribs from one OS:
> > Linux. I do not want to loose fat attributes during backup.
> > This would also be useful for the Wine developers.

I think, at least we are agreed that xattr interface would be good for
the following operation.

    # ls /mnt
    resierfs_mnt ext2_mnt vfat_mnt foo_mnt bar_mnt
    # archiver --create --file /backup/file_has_all_data /mnt

Thanks.
-- 
OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>