On Oct 16, 2007 21:51 -0700, [EMAIL PROTECTED] wrote:
> On Wed, 17 Oct 2007, Theodore Ts'o wrote:
> >It has a number random cleanups and bug fixes, and two new features.
> >The first is uninitialized block groups, which allows fast mke2fs
> >operations plus as well as speeding up e2fsck by allowin
Hi,
On Thursday 18 October 2007 16:24, Vasily Averin wrote:
> Hi all,
>
> could anybody explain how "inactive" may be much greater than "cached"?
> stress test (http://weather.ou.edu/~apw/projects/stress/) that writes into
> removed files in cycle puts the node to the following state:
>
> MemTotal
Hi all,
could anybody explain how "inactive" may be much greater than "cached"?
stress test (http://weather.ou.edu/~apw/projects/stress/) that writes into
removed files in cycle puts the node to the following state:
MemTotal: 16401648 kB
MemFree: 636644 kB
Buffers: 1122556 kB
Cached: 362880 kB
Sw
On Oct 16, 2007 21:17 -0500, Eric Sandeen wrote:
> Eric Sandeen wrote:
> > Martin Habets wrote:
> >> I ran the ltp-full-20070930 tests on 2.6.23-rc9-mph4 (sparc32 SMP), and am
> >> seeing the following warnings:
> >
> > This makes me a little nervous about my change
> > ef2b02d3e617cb0400eedf2668
The patch titled
ext2-avoid-rec_len-overflow-with-64kb-block-size-checkpatch-fixes
has been added to the -mm tree. Its filename is
ext2-avoid-rec_len-overflow-with-64kb-block-size-checkpatch-fixes.patch
*** Remember to use Documentation/SubmitChecklist when testing your code ***
See h
The patch titled
ext2: avoid rec_len overflow with 64KB block size
has been added to the -mm tree. Its filename is
ext2-avoid-rec_len-overflow-with-64kb-block-size.patch
*** Remember to use Documentation/SubmitChecklist when testing your code ***
See http://www.zip.com.au/~akpm/linux/
On Thu, 11 Oct 2007 13:18:49 +0200 Jan Kara <[EMAIL PROTECTED]> wrote:
> With 64KB blocksize, a directory entry can have size 64KB which does not fit
> into 16 bits we have for entry lenght. So we store 0x instead and convert
> value when read from / written to disk.
btw, this changes ext2's
On Thu, 11 Oct 2007 13:18:49 +0200 Jan Kara <[EMAIL PROTECTED]> wrote:
> +static inline __le16 ext2_rec_len_to_disk(unsigned len)
> +{
> + if (len == (1 << 16))
> + return cpu_to_le16(EXT2_MAX_REC_LEN);
> + else if (len > (1 << 16))
> + BUG();
> + return cpu_to_
Hi,
On Tue, Oct 16, 2007 at 08:20:59PM -0500, Eric Sandeen wrote:
> Martin Habets wrote:
> > Hello,
> >
> > I ran the ltp-full-20070930 tests on 2.6.23-rc9-mph4 (sparc32 SMP), and am
> > seeing the following warnings:
>
> This makes me a little nervous about my change
> ef2b02d3e617cb0400eedf266
On Oct 16, 2007 15:00 -0700, Andrew Morton wrote:
> On Fri, 13 Jul 2007 18:36:54 -0700
> Badari Pulavarty <[EMAIL PROTECTED]> wrote:
> > @@ -1136,12 +1136,12 @@ static int ext2_statfs (struct dentry *
> > buf->f_type = EXT2_SUPER_MAGIC;
> > buf->f_bsize = sb->s_blocksize;
> > buf->f_b
The patch titled
ext3: fix setup_new_group_blocks locking
has been added to the -mm tree. Its filename is
ext3-fix-setup_new_group_blocks-locking.patch
*** Remember to use Documentation/SubmitChecklist when testing your code ***
See http://www.zip.com.au/~akpm/linux/patches/stuff/adde
On Wed, Oct 17, 2007 at 08:59:53AM -0700, Linus Torvalds wrote:
> > Please pull from:
> >
> > git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4.git
> > for_linus
>
> This conflicts in nontrivial ways with
>
> which I just merged from -mm.
>
> I suspect it's trivial to fix up for
On Oct 16, 2007 13:09 +0530, Aneesh Kumar K.V wrote:
> I am wondering whether we can use i_size_high without looking at
> file mode (why restrict only to regular files ? )
Well, traditionally this was restricted to S_IFREG files, but to be honest
I've thought recently that directories should als
On Wed, 17 Oct 2007, Theodore Ts'o wrote:
>
> Please pull from:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4.git for_linus
This conflicts in nontrivial ways with
commit 7c9e69faa28027913ee059c285a5ea8382e24b5d
Author: Aneesh Kumar K.V <[EMAIL PROTECTED]
On Wed, Oct 17, 2007 at 04:13:50PM +0200, Valerie Clement wrote:
> Theodore Tso wrote:
>> It's good to clean this up, but this presumes that blk_t is going to
>> change to a 64-bit type. I'd much rather *add* a blk64_t, and keep
>> blk_t at 32 bits. This patch series in a number of places makes t
Theodore Tso wrote:
It's good to clean this up, but this presumes that blk_t is going to
change to a 64-bit type. I'd much rather *add* a blk64_t, and keep
blk_t at 32 bits. This patch series in a number of places makes the
presumption that blk_t will change size --- in particular when it
creat
The patch titled
convert ill defined log2() to ilog2()
has been removed from the -mm tree. Its filename was
convert-ill-defined-log2-to-ilog2.patch
This patch was dropped because it is obsolete
--
Subject: convert ill defined log2()
From: Fengguang Wu <[EMAIL PROTECTED]>
It's *wrong* to have
#define log2(n) ffz(~(n))
It should be *reversed*:
#define log2(n) flz(~(n))
or
#define log2(n) fls(n)
or just use
ilog2(n) defined in linux/l
From: Mathieu Desnoyers <[EMAIL PROTECTED]>
Fix f_version type: should be u64 instead of long
There is a type inconsistency between struct inode i_version and struct file
f_version.
fs.h:
struct inode
u64 i_version;
and
struct file
unsigned long f_version;
U
19 matches
Mail list logo
