On Tue, Jul 03, 2007 at 05:32:00PM -0600, Andreas Dilger wrote:
On Jul 03, 2007 18:15 -0400, J. Bruce Fields wrote:
How will nfsd tell whether it can really on a given filesystem's
i_version, or whether it should fall back on ctime?
Good question.
Well, we don't need anything
During a discussion at OLS, I came up with a very simple way of validating
the ext2/3/4 block bitmaps at read time. Until such a time when we have
checksums for the bitmaps we can have a simple but quite robust mechanism
that is useful for ext2/3/4.
When a new block bitmap is read from disk in
Valerie Henson wrote:
On Fri, Jun 29, 2007 at 06:07:25PM -0400, Mike Waychison wrote:
Relying on (a tweaked) reservations code is also somewhat limitting at
this stage given that reservations are lost on close(fd). Unless we
change the lifetime of the reservations (maybe for the lifetime of
Badari Pulavarty wrote:
On Sat, 2007-06-30 at 10:13 -0400, Mingming Cao wrote:
On Fri, 2007-06-29 at 13:01 -0700, Andrew Morton wrote:
Guys, Mike and Sreenivasa at google are looking into implementing
fallocate() on ext2. Of course, any such implementation could and should
also be portable to
On Jul 06, 2007 09:51 -0400, J. Bruce Fields wrote:
The use of a mount option means the change attribute could be
inconsistent across mounts. If we really need this, wouldn't it make
more sense for it to be a persistent feature of the filesystem, set at
mkfs time?
Yes, having it stored into
On Fri, 2007-07-06 at 14:33 -0700, Mike Waychison wrote:
Badari Pulavarty wrote:
On Sat, 2007-06-30 at 10:13 -0400, Mingming Cao wrote:
On Fri, 2007-06-29 at 13:01 -0700, Andrew Morton wrote:
Guys, Mike and Sreenivasa at google are looking into implementing
fallocate() on ext2. Of
