Re: [PATCH] Add a pair of system calls to make extended file stats available [ver #3]

[Andreas Dilger]

On 2010-07-05, at 08:59, David Howells wrote:
> Michael Kerrisk <mtk.manpages@xxxxxxxxx> wrote:
> 
>> * Include information from the "inode_info" structure, most notably
>> i_flags, but perhaps other info as well.
> 
> This thought has occurred to me, but are the contents of i_flags identical for
> all filesystems?  Certainly, i_flags doesn't seem to match the FS_IOC_GETFLAGS
> mask.  For example:
> 
> 	#define	FS_SECRM_FL			0x00000001
> 
> vs:
> 
> 	#define S_SYNC		1	/* Writes are synced at once */
> 
> (1) Does it make sense to rearrange the S_xxxx flags to match the numbers for
>   FS_xxxx_FL?

I saw your patch to that effect.  I'm of mixed feelings about this, since the S_* flags have traditionally been changed on an ad-hoc basis and I don't necessarily want to let this leak into the on-disk format of these flags for ext*.

One way to ensure that this holds true is to have a compile-time assertion that the respective S_* flags match FS_*_FL and EXT_*_FL.

We use a macro in Lustre for compile-time assertions that depends on the detection of duplicate values in a switch() statement:

/** Compile-time assertion.
* Check an invariant described by a constant expression at compile time by
* forcing a compiler error if it does not hold.  @cond must be a constant
* expression as defined by the ISO C Standard:
*
*       6.8.4.2  The switch statement
*       ....
*       [#3] The expression of each case label shall be  an  integer
*       constant   expression  and  no  two  of  the  case  constant
*       expressions in the same switch statement shall have the same
*       value after conversion...
*
*/
#define CLASSERT(cond) do {switch(42) {case (cond): case 0: break;}} while (0)

> (2) Does it make sense to do the BSD st_flags compatibility in userspace?
> 
> (3) Can we add a couple more flags to make Samba's life easier?  Say an
>   archived bit and a hidden bit?

I wouldn't object to that.  The BSD flags indicate that the hidden bit should only affect GUI display managers, not "ls".

> (4) Do I actually need to provide a mask saying what st_flags are applicable
>   to the file you've just queried?

Hmm, good question.

> (5) How often are these flags required?  E.g. does it make more sense to keep
>   them as an additional result, or does it make sense to stick them in the
>   kstat and xstat structs, knowing that these are allocated on the kernel
>   stack maybe as three times if an ecryptfs file?

If they aren't requested by userspace, the cost is mostly irrelevant.  I think on OSX these flags are returned for every "ls" call, to mark the inodes with xattrs every time.

Cheers, Andreas





--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/