17 Aug, 2011

1 commit

  • For a long time now orlov is the default block allocator in the ext3. It
    performs better than the old one and no one seems to claim otherwise so
    we can safely drop it and make oldalloc and orlov mount option
    deprecated.

    Signed-off-by: Lukas Czerner
    Signed-off-by: Jan Kara

    Lukas Czerner
     

25 Jul, 2011

1 commit


25 Jun, 2011

1 commit


22 May, 2010

1 commit

  • ext4 was updated to accept barrier/nobarrier mount options
    in addition to the older barrier=0/1. The barrier story
    is complex enough, we should help people by making the options
    the same at least, even if the defaults are different.

    This patch allows the barrier/nobarrier mount options for ext3,
    while keeping nobarrier the default.

    It also unconditionally displays barrier status in show_options,
    and prints a message at mount time if barriers are not enabled,
    just as ext4 does.

    Signed-off-by: Eric Sandeen
    Signed-off-by: Jan Kara

    Eric Sandeen
     

10 Dec, 2009

1 commit

  • Users on the list recently complained about differences across
    filesystems w.r.t. how to mount without a journal replay.

    In the discussion it was noted that xfs's "norecovery" option is
    perhaps more descriptively accurate than "noload," so let's make
    that an alias for ext3.

    Also show this status in /proc/mounts

    Signed-off-by: Eric Sandeen
    Signed-off-by: Jan Kara

    Eric Sandeen
     

13 Oct, 2009

1 commit


30 Mar, 2009

1 commit


13 Mar, 2009

1 commit


20 Oct, 2008

1 commit

  • If the journal doesn't abort when it gets an IO error in file data blocks,
    the file data corruption will spread silently. Because most of
    applications and commands do buffered writes without fsync(), they don't
    notice the IO error. It's scary for mission critical systems. On the
    other hand, if the journal aborts whenever it gets an IO error in file
    data blocks, the system will easily become inoperable. So this patch
    introduces a filesystem option to determine whether it aborts the journal
    or just call printk() when it gets an IO error in file data.

    If you mount a ext3 fs with data_err=abort option, it aborts on file data
    write error. If you mount it with data_err=ignore, it doesn't abort, just
    call printk(). data_err=ignore is the default.

    Signed-off-by: Hidehiro Kawai
    Cc: Jan Kara
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Hidehiro Kawai
     

17 Oct, 2008

1 commit

  • Remove Andrew Morton's http://www.zip.com.au/~akpm/ urls, update to new
    ones when necessary, delete references otherwise.

    There are still instances of that living in:
    Documentation/zh_CN/HOWTO
    Documentation/zh_CN/SubmittingPatches
    Documentation/ko_KR/HOWTO
    Documentation/ja_JP/SubmittingPatches

    Signed-off-by: Francois Cami
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    FD Cami
     

20 Oct, 2007

1 commit


27 Jun, 2006

1 commit

  • This patch adds "-o bh" option to force use of buffer_heads. This option
    is needed when we make "nobh" as default - and if we run into problems.

    Signed-off-by: Badari Pulavarty
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Badari Pulavarty
     

12 Jan, 2006

1 commit

  • Undocument the non-working resize= mount option in ext3, and add some
    references to the ext2resize package instead, which appears to be the only
    proper way of doing online resizing of ext3 filesystems.

    Signed-off-by: Tore Anderson
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Tore Anderson
     

11 Jan, 2006

1 commit


09 Jan, 2006

1 commit


13 Dec, 2005

1 commit


17 Apr, 2005

1 commit

  • Initial git repository build. I'm not bothering with the full history,
    even though we have it. We can create a separate "historical" git
    archive of that later if we want to, and in the meantime it's about
    3.2GB when imported into git - space that would just make the early
    git days unnecessarily complicated, when we don't have a lot of good
    infrastructure for it.

    Let it rip!

    Linus Torvalds