On Thu, Jun 28, 2007 at 11:33:42AM -0700, Andrew Morton wrote:
I think Mingming was asking that Ted move the current quilt tree into git,
presumably because she's working off git.
I'm not sure what to do, really. The core kernel patches need to be in
Ted's tree for testing but that'll
On Thu, Jun 28, 2007 at 11:33:42AM -0700, Andrew Morton wrote:
Please let us know what you think of Mingming's suggestion of posting
all the fallocate patches including the ext4 ones as incremental ones
against the -mm.
I think Mingming was asking that Ted move the current quilt tree into
Theodore Tso wrote:
I don't think we have a problem here. What we have now is fine, and
It's fine for ext4, but not the wider world. This is a common problem
created by parallel development when code dependencies exist.
In any case, the plan is to push all of the core bits into Linus
Theodore Tso wrote:
On Thu, Jun 28, 2007 at 11:33:42AM -0700, Andrew Morton wrote:
Please let us know what you think of Mingming's suggestion of posting
all the fallocate patches including the ext4 ones as incremental ones
against the -mm.
I think Mingming was asking that Ted move
On Fri, Jun 29, 2007 at 10:29:21AM -0400, Jeff Garzik wrote:
In any case, the plan is to push all of the core bits into Linus tree
for 2.6.22 once it opens up, which should be Real Soon Now, it looks
like.
Presumably you mean 2.6.23.
Yes, sorry. I meant once Linus releases 2.6.22, and we
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 ext3 and ext4 bitmapped files.
I believe that Sreenivasa will mainly be doing the implementation work.
The basic plan is as follows:
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 ext3 and ext4 bitmapped files.
I believe that Sreenivasa will mainly be
Dave Kleikamp 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 ext3 and ext4 bitmapped files.
I believe that Sreenivasa
On Fri, Jun 29, 2007 at 01:01:20PM -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 ext3 and ext4 bitmapped files.
What's the eventual goal of this work?
On Fri, 2007-06-29 at 16:52 -0400, Mike Waychison wrote:
Dave Kleikamp wrote:
By truncating the blocks file at the correct byte offset, only needing
to zero some bits of the last byte of the file.
We were thinking the unwritten blocks file would be indexed by physical
block number of
On Fri, 29 Jun 2007 16:55:25 -0400
Theodore Tso [EMAIL PROTECTED] wrote:
On Fri, Jun 29, 2007 at 01:01:20PM -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
On Jun 29, 2007 16:55 -0400, Theodore Tso wrote:
What's the eventual goal of this work? Would it be for mainline use,
or just something that would be used internally at Google? I'm not
particularly ennthused about supporting two ways of doing fallocate();
one for ext4 and one for
Am Montag 25 Juni 2007 schrieb Theodore Ts'o:
... contains what I hope to be the e2fsprogs 1.40 release. If folks
could test it and let me know if they find any embarassing bugs, I would
greatly appreciate it. It can also be found at:
There are a bunch of patches applied in the gentoo
Andrew Morton wrote:
On Fri, 29 Jun 2007 16:55:25 -0400
Theodore Tso [EMAIL PROTECTED] wrote:
On Fri, Jun 29, 2007 at 01:01:20PM -0700, Andrew Morton wrote:
Guys, Mike and Sreenivasa at google are looking into implementing
fallocate() on ext2. Of course, any such implementation could and
Hi folks,
I've been looking at getting around some of the limitations imposed by
the block groups and was wondering what are peoples thoughts about
implementing this using either bigger block groups or storing the
bitmaps and inode tables outside of the block groups.
I think the BIG_BG feature
Andreas Dilger wrote:
On Jun 29, 2007 16:55 -0400, Theodore Tso wrote:
What's the eventual goal of this work? Would it be for mainline use,
or just something that would be used internally at Google? I'm not
particularly ennthused about supporting two ways of doing fallocate();
one for ext4
On Fri, Jun 29, 2007 at 11:51:29PM +0200, Hanno Böck wrote:
Am Montag 25 Juni 2007 schrieb Theodore Ts'o:
... contains what I hope to be the e2fsprogs 1.40 release. If folks
could test it and let me know if they find any embarassing bugs, I would
greatly appreciate it. It can also be
On Jun 29, 2007 18:26 -0400, Mike Waychison wrote:
Andreas Dilger wrote:
I don't think ext2 is safe for 8TB filesystems anyways, so this
isn't a huge loss.
This is reference to the idea of overloading the high-bit and not
related to the PAGE_SIZE blocks correct?
Correct - just that the
On Jun 29, 2007 17:09 -0500, Jose R. Santos wrote:
I think the BIG_BG feature is better suited to the design philosophy of
ext2/3. Since all the important meta-data is easily accessible thanks
to the static filesystem layout, I would expect for easier fsck
recovery. This should also
19 matches
Mail list logo
