ith this approach is that we'd have
difficult reclaiming the metadata indirect blocks from the backing inode
efficiently. So if a user went and pre-allocated say 1GB of disk space
for a file, we'd end up with the ~%0.1 metadata overhead doubled until
we see the i_blocks for the backing i
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
ough I'm not certain it's ready for our
consumption.
What are people's thoughts on providing ext3 non-journal mode? We could
benefit from several of the additions to ext3 that aren't available in
ext2 and disabling journalling there sounds much more feasible for us
instead of t
the lifetime of the reservations (maybe for the lifetime of the
in-core inode?), crank up the reservation sizes and deal with the
overcommit issues, I can't think of any better way at this time to deal
with the problem.
Mike Waychison
-
To unsubscribe from this list: send the line
s more
important to make sure it can't be mounted by an older kernel if bad
things can happen, and they can.
Ya, I too was originally thinking of a compat flag to keep the old
kernel from mounting the filesystem. We'd arrange our bootup scripts to
check for compatibility and call
