Re: [PATCH] shmem: restore superblock info

[Brent Casavant <bcasavan@sgi.com>]

On Mon, 6 Jun 2005, Hugh Dickins wrote:

> @@ -1607,15 +1582,17 @@ static int shmem_statfs(struct super_blo
>  	buf->f_type = TMPFS_MAGIC;
>  	buf->f_bsize = PAGE_CACHE_SIZE;
>  	buf->f_namelen = NAME_MAX;
> -	if (sbinfo) {
> -		spin_lock(&sbinfo->stat_lock);
> +	spin_lock(&sbinfo->stat_lock);
> +	if (sbinfo->max_blocks) {
>  		buf->f_blocks = sbinfo->max_blocks;
>  		buf->f_bavail = buf->f_bfree = sbinfo->free_blocks;
> +	}
> +	if (sbinfo->max_inodes) {
>  		buf->f_files = sbinfo->max_inodes;
>  		buf->f_ffree = sbinfo->free_inodes;
> -		spin_unlock(&sbinfo->stat_lock);
>  	}
>  	/* else leave those fields 0 like simple_statfs */
> +	spin_unlock(&sbinfo->stat_lock);
>  	return 0;
>  }

This is the only change I'm at all concerned about.

I'm not sure how frequent statfs operations occur in practice (I suspect
infrequently), however simply changing the existing code from "if (sbinfo)"
to "if (sbinfo->max_blocks || sbinfo->max_inodes)" would be an appropriate
remedy if there is a real problem.

That said, I'm not all that concerned about it, as my fuzzy memory
indicates it was the lock/unlock around the statistics updates which
caused the primary lock contention.

Brent

-- 
Brent Casavant                          If you had nothing to fear,
bcasavan@sgi.com                        how then could you be brave?
Silicon Graphics, Inc.                    -- Queen Dama, Source Wars
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/