Mathieu Segaud <[EMAIL PROTECTED]> writes:
> Signed-off-by: Mathieu Segaud <[EMAIL PROTECTED]>
> ---
> fs/ext4/dir.c |2 +-
> fs/ext4/file.c |2 +-
> fs/ext4/ioctl.c | 161
> ---
> include/linux/ext4_fs.h |3 +-
>
On Thu, 2008-01-24 at 18:40 -0500, Theodore Tso wrote:
> On Fri, Jan 25, 2008 at 01:08:09AM +0200, Adrian Bunk wrote:
> > In practice, there is a small number of programs that are both the
> > common memory hogs and should be able to reduce their memory consumption
> > by 10% or 20% without big pr
On Fri, Jan 25, 2008 at 01:08:09AM +0200, Adrian Bunk wrote:
> In practice, there is a small number of programs that are both the
> common memory hogs and should be able to reduce their memory consumption
> by 10% or 20% without big problems when requested (e.g. Java VMs,
> Firefox and databases co
On Thu, Jan 24, 2008 at 06:32:15PM +0100, Bodo Eggert wrote:
> Alan Cox <[EMAIL PROTECTED]> wrote:
>
> >> I'd tried to advocate SIGDANGER some years ago as well, but none of
> >> the kernel maintainers were interested. It definitely makes sense
> >> to have some sort of mechanism like this. At t
On Jan 24, 2008 18:32 +0100, Bodo Eggert wrote:
> I think a single, system-wide signal is the second-to worst solution: All
> applications (or the wrong one, if you select one) would free their caches
> and start to crawl, and either stay in this state or slowly increase their
> caches again until
Andreas Dilger wrote:
> Eric, I haven't looked at the FC8/9 e2fsprogs yet, but do they also have
> a ton of patches (possibly in the -pu branch), or do they track upstream
> more closely?
I try to track upstream as closely as I can; F8 had quite a lot of
patches for a while, and I got it whittled
On Wed, 2008-01-23 at 14:07 -0800, Andrew Morton wrote:
> > On Mon, 21 Jan 2008 22:02:12 -0500 "Theodore Ts'o" <[EMAIL PROTECTED]>
> > wrote:
> > From: Girish Shilamkar <[EMAIL PROTECTED]>
> >
> > The journal checksum feature adds two new flags i.e
> > JBD2_FEATURE_INCOMPAT_ASYNC_COMMIT and JBD2_
I was looking through the SLES10 e2fsprogs patch set, and I wonder if some
of them could be integrated upstream, and if any effort had been made in
that direction in the past? In particular, the addition of et_list_lock()
and et_list_unlock() to libcom_err cause failures if e2fsprogs is updated
to
On Thu, 2008-01-24 at 20:20 +0530, Aneesh Kumar K.V wrote:
> I have updated patches based on the review feedback from Andrew.
>
> I have tested this on
> 128(64p) ppc64sles
> 4(2p)ppc64 debian
> 4(2p) x86_64 ubuntu-gutsy
>
> Updated patches are at
> http://www.radian.org/~kvaneesh/
On Sunday 20 January 2008 18:51, Theodore Tso wrote:
> On Sat, Jan 19, 2008 at 08:10:20PM -0800, Daniel Phillips wrote:
> > I can see value in preemptively loading indirect blocks into the
> > buffer cache, but is building a second-order extent tree really
> > worth the effort? Probing the buffer
Alan Cox <[EMAIL PROTECTED]> wrote:
>> I'd tried to advocate SIGDANGER some years ago as well, but none of
>> the kernel maintainers were interested. It definitely makes sense
>> to have some sort of mechanism like this. At the time I first brought
>> it up it was in conjunction with Netscape us
Andreas Dilger wrote:
> On Jan 24, 2008 20:20 +0530, Aneesh Kumar K.V wrote:
>> @@ -89,6 +89,8 @@ When mounting an ext4 filesystem, the following option are
>> accepted:
>> extents ext4 will use extents to address file data. The
>> file system will no lo
On Jan 24, 2008 20:20 +0530, Aneesh Kumar K.V wrote:
> @@ -89,6 +89,8 @@ When mounting an ext4 filesystem, the following option are
> accepted:
> extents ext4 will use extents to address file data. The
> file system will no longer be mountable by ext3.
Hi,
I looked at the GFP flag usage in mballoc. I think the below change
make sense with respect to mballoc.
First hunk is memory allocation during ext4_mb_init which is called
during mount time. I guess it is ok to convert that to GFP_KERNEL.
Second hunk is during ext4_mb_free_metadata. I gues
On Thu, Jan 24, 2008 at 01:26:14PM +0530, Aneesh Kumar K.V wrote:
>
> >
> > > +/* find most significant bit */
> > > +static int fmsb(unsigned short word)
> > > +{
> > > + int order;
> > > +
> > > + if (word > 255) {
> > > + order = 7;
> > > + word >>= 8;
> > > + } else {
> > > +
I have updated patches based on the review feedback from Andrew.
I have tested this on
128(64p) ppc64 sles
4(2p)ppc64 debian
4(2p)x86_64 ubuntu-gutsy
Updated patches are at
http://www.radian.org/~kvaneesh/ext4/jan-24-2008/
http://www.radian.org/~kvaneesh/ext4/jan-24-2008/patches.tar
D
No, it didn't. I measured read from a 10GB sequentially laid out file
with standard benchmarking practices (cold cache, multiple runs, low
std. deviation in results, etc.) and here are the results:
File created by vanilla Ext3 being read by vanilla Ext3:
Total: 3m16.1s
User: 0.0.5s
Sys: 13.9
File
On Wed, Jan 23, 2008 at 02:06:59PM -0800, Andrew Morton wrote:
> > On Mon, 21 Jan 2008 22:02:09 -0500 "Theodore Ts'o" <[EMAIL PROTECTED]>
> > wrote:
> > +int ext4_get_blocks_wrap(handle_t *handle, struct inode *inode, sector_t
> > block,
> > + unsigned long max_blocks, struct bu
updated patch. Waiting for the test results.
I am only attaching the diff. Mballoc patch is really large.
-aneesh
diff --git a/Documentation/filesystems/ext4.txt
b/Documentation/filesystems/ext4.txt
index 4f329af..ec7d349 100644
--- a/Documentation/filesystems/ext4.txt
+++ b/Documentation/filesy
> On Thu, 24 Jan 2008 10:52:27 +0530 "Aneesh Kumar K.V" <[EMAIL PROTECTED]>
> wrote:
> + * Returns zero on success and -EIO on error.If the input
> + * buffer is not locked returns -EINVAL
> + *
> + */
> +int bh_submit_read(struct buffer_head *bh)
> +{
> + if (!buffer_locked(bh))
> +
20 matches
Mail list logo
