In message <Pine.LNX.4.64.0610131615370.563@xxxxxxxxxxxxxxxxxxxxx>, Pekka J Enberg writes:
> From: Pekka Enberg <penberg@xxxxxxxxxxxxxx>
>
> Add generic functions for obtaining the hidden object (superblock, inode,
> dentry, and dentry mount-point) in a stacked filesystem. As fan-out
> stacked filesystems have multiple hidden objects, we store them in a
> statically allocated array of pointers. The current hard-coded limit
> STACKFS_MAX_BRANCHES is not enough for unionfs (for which users have more
> than 100 branches). That, however, can be fixed later for unionfs.
I think we should do it right the first time (i.e., now :-)
> +#define STACKFS_MAX_BRANCHES (8)
> +struct stackfs_sb_info {
> + struct super_block *hidden_sbs[STACKFS_MAX_BRANCHES];
> +};
Why not make it something more dynamic, such as a mount-time option per sb?
Even at 8, you waste most of that space for non-fan-out stackable file
systems such as ecryptfs; and those unionfs users who want more, will have
to _recompile_ the code.
And given that this code is shared, if just one f/s needs 100 branches, why
should ecryptfs waste 99*sizeof(pointer) bytes for every *_info structure?
> +static inline struct super_block *
> +__stackfs_hidden_sb(struct super_block *sb, unsigned long branch_idx)
> +{
> + struct stackfs_sb_info *info = sb->s_fs_info;
> + return info->hidden_sbs[branch_idx];
> +}
Also, the functions don't check array bounds. Where, if at all, this gets
checked against the STACKFS_MAX_BRANCHES value? Shouldn't we at least put
some ASSERT's in there to catch bugs?
Of course, I realize that the above code is rather simple now and changing
it as I propose will require kmalloc/kfree (or containers) carefully used
throughout.
Thanks,
Erez.
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
