[lkml]   [1999]   [Feb]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: fsync on large files

    On Wed, 17 Feb 1999 09:43:57 -0800 (PST), Linus Torvalds
    <> said:

    > Good. Then don't go around calling it ext2 any more. I don't want to have
    > people even _wondering_ about the stability of the central Linux
    > filesystem.

    It _isn't_ called ext2. It is called ext3.

    > I would also suggest that Stephen actually drop ext2
    > altogether. There's just too much historical stuff in most
    > filesystems - things like having "." and ".." in directories, even
    > though Linux doesn't need them and they only complicate renaming and
    > loopback mounting a lot.

    Linus, this makes very little sense right now: there is an _urgent_
    need for a journaled filesystem for Linux, and there is an urgent need
    for a solution which is of production quality. Implementing a new
    filesystem from scratch is hardly the way to achieve that. The
    recovery time of ext2 on large filesystems is a real showstopper to
    many potential applications.

    > I think that if people are doing a new filesystem, it should be done
    > like "ext2" was originally done: by designing a new one, rather than
    > building more scaffolding on top of an old one.

    Then please check what I'm actually trying to do. I am explicitly
    _not_ designing a new filesystem.

    The journaling implemented so far is a way of committing multiple
    buffer updates to disk atomically, using some region of disk to hold a
    journal of the in-progress updates. The functionality is designed to
    be sufficient to journal any typical filesystem. It will also be
    flexible enough to journal reiserfs and Ingo's LVM stuff (there are
    several things we want to do with LVM which will require atomic
    updates across multiple block devices to be stable).

    The ext3 code is nothing more than a set of calls to demarkate the
    start and end of complete, consistent filesystem operations.

    > There's also a lot of code to handle concurrent writes etc, which
    > can't happen any more.

    The fact that it cannot happen is a problem for scalable IO to
    database files: the only existing standard Unix API which makes any
    sense at all in that environment is O_SYNC IO with threads
    (ie. asynchronous IO but with synchronous completion), and concurrent
    writes are a must-have in that case. If you are saying you will
    reject a patch to restore that behaviour then we must be on different
    planets. The atomic write behaviour is a by-product of fixing an
    entirely different problem (concurrent truncate, for which making it
    atomic does make a lot of sense).


    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 13:50    [from the cache]
    ©2003-2014 Jasper Spaans. hosted at Digital Ocean