headers
Alan Cox | 1 May 2008 01:20
Picon

Re: [PATCH] ext3: Fix typos in messages and comments (journalled -> journaled)

> > A search of the ACM literature finds "journalized", "journalled" and
> > "journaled" are all in use for this operation.
> 
> I hate to get into these discussions, but I've used "journaled" a lot,
> so I feel I should chime in.

I noticed and IBM cannot even agree internally 8)

"Tivoli Storage Manager Journal Based Backup troubleshooting techniques
 and solutions to common problems seen with journalized backups and the
 journal database. This is from a 2005_November_07 Support Technical
 Exchange Web seminar presented by TSM Support staff"

"IBM Journaled File System (JFS)"

> That would probably be more correct, but the use of "journal" as a verb
> has really gotten ingrained in file system developers brains.  I
> personally haven't heard or used "journalized" and it would take some
> getting used to.

Mandrake use Journalized File System in various press articles. Mac
people seem to like journalized too and google shows it used in various
reviews and articles.

I think I'm going to follow this up with the professional bodies and see
if there is an opinion because either the computing world needs to agree
on a proper English name, or they need to agree on a new one and talk to
the dictionary people about it.

Alan
(Continue reading)

Permalink | Reply | 6 comments |
headers
Dave Kleikamp | 1 May 2008 04:28
Picon

Re: [PATCH] ext3: Fix typos in messages and comments (journalled -> journaled)


On Thu, 2008-05-01 at 00:20 +0100, Alan Cox wrote:
> > > A search of the ACM literature finds "journalized", "journalled" and
> > > "journaled" are all in use for this operation.
> > 
> > I hate to get into these discussions, but I've used "journaled" a lot,
> > so I feel I should chime in.
> 
> I noticed and IBM cannot even agree internally 8)
> 
> "Tivoli Storage Manager Journal Based Backup troubleshooting techniques
>  and solutions to common problems seen with journalized backups and the
>  journal database. This is from a 2005_November_07 Support Technical
>  Exchange Web seminar presented by TSM Support staff"
> 
> "IBM Journaled File System (JFS)"

IBM's big.  What can I say?  :-)

> > That would probably be more correct, but the use of "journal" as a verb
> > has really gotten ingrained in file system developers brains.  I
> > personally haven't heard or used "journalized" and it would take some
> > getting used to.
> 
> Mandrake use Journalized File System in various press articles. Mac
> people seem to like journalized too and google shows it used in various
> reviews and articles.

I guess it's more common that I thought.
(Continue reading)

Permalink | Reply | 2 comments |
headers
Alan Cox | 1 May 2008 11:47
Picon

Re: [PATCH] ext3: Fix typos in messages and comments (journalled -> journaled)

> > I think I'm going to follow this up with the professional bodies and see
> > if there is an opinion because either the computing world needs to agree
> > on a proper English name, or they need to agree on a new one and talk to
> > the dictionary people about it.
> 
> If there's some kind of consensus, I don't have strong feelings either
> way.

BCS: "BCS use the OED as the final arbiter, without the zeds though...so
journalise is what we'd use if we absolutely had to."

I don't know if anyone has the right ACM contacts to find out what the
other big professional body thinks ?

Alan
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 0 comments |
headers
Joe Fegan | 1 May 2008 12:01
Picon
Favicon

RE: [PATCH] ext3: Fix typos in messages and comments (journalled -> journaled)


Then again, I would consider journalize to be the US version of journalise

> Date: Thu, 1 May 2008 00:20:18 +0100
> From: alan <at> lxorguk.ukuu.org.uk
> To: shaggy <at> linux.vnet.ibm.com
> CC: akpm <at> linux-foundation.org; jack <at> suse.cz; linux-kernel <at> vger.kernel.org; linux-ext4 <at> vger.kernel.org
> Subject: Re: [PATCH] ext3: Fix typos in messages and comments (journalled -> journaled)
>
>>> A search of the ACM literature finds "journalized", "journalled" and
>>> "journaled" are all in use for this operation.
>>
>> I hate to get into these discussions, but I've used "journaled" a lot,
>> so I feel I should chime in.
>
> I noticed and IBM cannot even agree internally 8)
>
> "Tivoli Storage Manager Journal Based Backup troubleshooting techniques
> and solutions to common problems seen with journalized backups and the
> journal database. This is from a 2005_November_07 Support Technical
> Exchange Web seminar presented by TSM Support staff"
>
> "IBM Journaled File System (JFS)"
>
>
>> That would probably be more correct, but the use of "journal" as a verb
>> has really gotten ingrained in file system developers brains. I
>> personally haven't heard or used "journalized" and it would take some
>> getting used to.
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Vegard Nossum | 1 May 2008 13:33
Picon

BUG in ext3_sync_fs

Hi,

With current git (+ kmemcheck, see below) patches I get the following
during boot:

BUG: unable to handle kernel paging request at 00001108
IP: [<c04effcf>] ext3_sync_fs+0x3f/+x80

I inserted some printks in ext3_sync_fs():
        printk(KERN_EMERG "sb = %p\n", sb);
        printk(KERN_EMERG "sb->s_fs_info = %p\n", sb->s_fs_info);

And they show:
sb = f7f61e00
sb->s_fs_info = 00000000

Monitorshot: http://folk.uio.no/vegardno/linux/DSCF2905.JPG
Config: http://folk.uio.no/vegardno/linux/config-20080501.txt

I am booting a USB stick with an ext2 filesystem as root partition. It
mounts fine in other machines.

It could of course be my kmemcheck patches that are causing this
(though I find it unlikely as they are disabled on boot => no-op, and
everything was fine a couple of days ago), but recompiling this config
takes a few hours, and I thought I'd just post early in case the
problem is really with ext3.

I can send vmlinux image and/or disk image if necessary.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Theodore Ts'o | 1 May 2008 16:40
Picon
Picon
Favicon

[PATCH, RFC] ext3: move headers out of include/linux

Move ext3 headers out of include/linux.  Cristoph promised to do this
once the ext4 patch was accepted, but I figured I'd do him a favor and
and do it for him.  :-)

People are angsting heavily over patches not going through linux-next or
-mm first on LKML at the moment, but this is a simple patch (just moving
header files around and adjusting #include's), so I'd like to get a
sense if this is something Linus would accept at this point.  It would
be nice to keep ext3 and ext4 in synch as much as possible, but it's not
the end of the world if this misses the merge window and we don't do
this until 2.6.27's merge window.

Secondly, Christoph, was there a reason why you didn't unpublish
ext2_fs.h when you unpublished ext3_fs.h?  Are there a significant
number of userspace prorams using it?  I don't care, because e2fsprogs
doesn't use it, and as far as I'm concerned I'd much rather encourage
people to use ext2fs/ext2_fs.h from e2fsprogs instead.  And this would
allow us to do a similar patch for fs/ext2; but assume you had found
some significant number of applications that would break if we
unexported and moved linux/ext2_fs.h?

Cc: Christoph Hellwig <hch <at> lst.de>
Signed-off-by: "Theodore Ts'o" <tytso <at> mit.edu>
---
 fs/ext3/acl.c              |    4 +-
 fs/ext3/balloc.c           |    5 +-
 fs/ext3/bitmap.c           |    2 +-
 fs/ext3/dir.c              |    3 +-
 fs/ext3/ext3.h             |  897 ++++++++++++++++++++++++++++++++++++++++++++
 fs/ext3/ext3_i.h           |  147 ++++++++
(Continue reading)

Permalink | Reply | 8 comments |
headers
Badari Pulavarty | 1 May 2008 17:16
Picon
Favicon

[PATCH] jbd_commit_transaction() races with journal_try_to_drop_buffers() causing DIO failures

Hi Andrew & Jan,

I was able to reproduce the customer problem involving DIO
(invalidate_inode_pages2) problem by writing simple testcase
to keep writing to a file using buffered writes and DIO writes
forever in a loop. I see DIO writes fail with -EIO.

After a long debug, found 2 cases how this could happen.
These are race conditions with journal_try_to_free_buffers()
and journal_commit_transaction().

1) journal_submit_data_buffers() tries to get bh_state lock. If
try lock fails, it drops the j_list_lock and sleeps for
bh_state lock, while holding a reference on the buffer.
In the meanwhile, journal_try_to_free_buffers() can clean up the
journal head could call try_to_free_buffers(). try_to_free_buffers()
would fail due to the reference held by journal_submit_data_buffers()
- which in turn causes failues for DIO (invalidate_inode_pages2()).

2) When the buffer is on t_locked_list waiting for IO to finish,
we hold a reference and give up the cpu, if we can't get
bh_state lock. This causes try_to_free_buffers() to fail.

Fix is to drop the reference on the buffer if we can't get
bh_state lock, give up the cpu and re-try the whole operation -
instead of waiting for the vh_state lock.

Does this look like a resonable fix ?

Thanks,
(Continue reading)

Permalink | Reply | 93 comments |
headers
Christoph Hellwig | 1 May 2008 17:30
Picon

Re: [PATCH, RFC] ext3: move headers out of include/linux

On Thu, May 01, 2008 at 10:40:37AM -0400, Theodore Ts'o wrote:
> Secondly, Christoph, was there a reason why you didn't unpublish
> ext2_fs.h when you unpublished ext3_fs.h?  Are there a significant
> number of userspace prorams using it?  I don't care, because e2fsprogs
> doesn't use it, and as far as I'm concerned I'd much rather encourage
> people to use ext2fs/ext2_fs.h from e2fsprogs instead.  And this would
> allow us to do a similar patch for fs/ext2; but assume you had found
> some significant number of applications that would break if we
> unexported and moved linux/ext2_fs.h?

ext2_fs.h has been there for much longer, and unlike ext3_fs.h it
actually is useable by userpsace.  Of course everyone should be using
the headers from e2fsprogs by now, but I'm not sure if that's really the
case.

In past cases like that Olaf did greps over the whole OpenSuSE tree,
so maybe he could do it for this aswell?

--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 2 comments |
headers
Aneesh Kumar K.V | 1 May 2008 17:37
Picon
Gravatar

Re: [PATCH] ext4: start seraching for the right extent from the goal group.

On Wed, Apr 30, 2008 at 07:58:35AM -0500, Eric Sandeen wrote:
> Aneesh Kumar K.V wrote:
> > With mballoc we search for the best extent using different
> > criteria. We should always use the goal group when we are
> > starting with a new criteria.
> 
> Aneesh, is there any testcase etc that will demonstrate the resulting
> difference in layout?
> 
> It's not clear to me from this changelog (without looking at a lot more
> context) exactly what you're changing and why...

I don't have any specific test case.  With mballoc depending on the
request size we follow different criteria to allocate blocks. For
example if the size is stripe size multiple we use criteria 1 and start
searching for the right blocks from block group starting with goal
group. If we don't find right count of blocks, we use criteria 2 and start
searching from the group block 0. I guess with criteria 2 also, we should start
searching from the goal group so that when we find the right count of
blocks we find them close to the goal group.

-aneesh
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 2 comments |
headers
Aneesh Kumar K.V | 1 May 2008 17:48
Picon
Gravatar

Re: [PATCH] ext4: start seraching for the right extent from the goal group.

On Wed, Apr 30, 2008 at 04:15:11PM +0200, Valerie Clement wrote:
> Aneesh Kumar K.V wrote:
>> With mballoc we search for the best extent using different
>> criteria. We should always use the goal group when we are
>> starting with a new criteria.
>
> Hi Aneesh,
>
> as you are working on the mballoc code, there is another thing
> which is not clear for me: why skipping uninitialized groups in  
> ext4_mb_good_group() when criteria is 0.
> I'm doing tests on large partition (~2TB) and on FS with 1KB
> block size and it impacts the performance when the number of
> groups is great (and the uninit_groups feature is used of course).
> For which reason we skip these groups ?
>

The reason is to avoid initializing block group. We would like to make
sure when we are allocating blocks we allocate them from already
initialized group. Otherwise we would end up initializing multiple block
group with in turn decrease the performance advantage of uninit_group.

The current logic is.

If request len is order of 2 we start with cr=0.

If we are cr=0 skip the uninit block group and search for the right
count of blocks in other initialized block group using simple_scan
logic.
(Continue reading)

Permalink | Reply | 0 comments |

Gmane