On 07/30/2011 10:34 PM, Dave Chinner wrote:
On Fri, Jul 29, 2011 at 05:44:19PM +0400, Glauber Costa wrote:
This patch introduces a simple generic vfs option parser.
Right now, the only option we have is to limit the size of the dcache.
So any user that wants to have a dcache entries limit, can specify:
mount -o whatever_options,vfs_dcache_size=XXX<dev> <mntpoint>
It is supposed to work well with remounts, allowing it to change
multiple over the course of the filesystem's lifecycle.
I find mount a natural interface for handling filesystem options,
so that's what I've choosen. Feel free to yell at it at will if
you disagree.
IMO, the whole point of having a configurable cache size maximum is
that is can be changed at runtime. Tying it to mount options is a
painful way to acheive that because the only way to change it would
be via a remount command.
And what's wrong with a remount command? It's a quite natural operation.
Furthermore, changing it at runtime is important - and as you noted,
quite doable, but it is not "the whole point of it".
The whole point of it is to allow a piece of the fs hierarchy to have
a limit on the cache sizes. So I expect the most common usage to be
at mount itself. Specifically for the use case I have in mind, when
a new container is created.
I'm not sure what the best API is, but I'd prefer something that is
specific to a superblock, not a vfs mount. Perhaps something in
/sys/fs?
I am not sure either, but I still believe my proposal is superior to
write-to-a-file specifically. Writing to a file, be it in proc, sys, or
wherever, leaves a window of opportunity open between mounting a
filesystem and limiting its caches. Doing it on mount is atomic.
Effectively, I see this limit as a property of a particular instance of
a mounted filesystem. Since all properties of a filesystem are specified
during mount, this becomes a natural extension.
Let me know what you think
--
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
