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: [email protected]
Phone: (650) 506-8127
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]