On Mon, Jun 19, 2006 at 01:06:27PM -0400, Theodore Tso wrote:
> How strongly do you feel about reporting stat.st_blksize out to be the
> clustersize?  Keeping in mind that if you report a value which is too
> big, /bin/cp will start coredumping....

	What's "too big"?  We certainly don't specify 128MB, but we will
specify up to 1MB.
	When we have large cluster size filesystems, we've seen backups
with O_DIRECT-enabled versions of cp(1) and dd(1) go way faster than
when they read/write 4K at a time.  This matters to folks who have the
files open O_DIRECT by other processes and cannot trust the page cache.
At least, that's is how it was when we originally did this :-)

> If I take Christoph's suggestion of simply removing sb->s_blksize
> altogether, and forcing filesystems that want to return a non-default
> value for stat.st_blksize to supply their own filesystem-specific
> getattr, will you mind terribly?

	Well, Christoph points out we already have a valid getattr()
that calls generic_fillattr() and then overloads our stat->blksize.  So
I think we're safe.  I don't think we need sb->s_blksize, but I'll defer
to Mark for the final say.

Joel

-- 

"The lawgiver, of all beings, most owes the law allegiance.  He of all
 men should behave as though the law compelled him.  But it is the
 universal weakness of mankind that what we are given to administer we
 presently imagine we own."
        - H.G. Wells

Joel Becker
Principal Software Developer
Oracle
E-mail: joel.becker@oracle.com
Phone: (650) 506-8127
-
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/