lkml.org 
[lkml]   [2002]   [Feb]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: ext3 and undeletion
    On Feb 26, 2002  14:56 -0300, Rik van Riel wrote:
    > On Tue, 26 Feb 2002, Rose, Billy wrote:
    > > My company can tolerate 0% loss of data (which is why I raised this issue).
    >
    > > The ability to handle situations like a file going "poof" is why my
    > > company will not use Linux on these particular file servers. My aim was
    > > to change that by crushing the only thing holding Netware in my company.
    >
    > You could use LVM snapshots.

    No, LVM snapshots are not really practical for such applications. The
    real problem is that (a) you are limited to 256 LVs with the current
    LVM code, so maybe hourly snapshots on 10 filesystems probably isn't
    enough, and (b) you have to make a copy of the data for _each_ LVM
    snapshot that you have, which quickly becomes expensive for a large
    number of snapshots.

    At one time there was a SnapFS project at SourceForge (for which I
    wrote the original ext2 shapshot code), but it appears to have gone
    into oblivion and the current "maintainers" are not responsive to
    requests to make this available.

    SnapFS has the benefits of only keeping a single copy of each version
    of the file, and you can make a larger number of snapshots than with
    LVM with no overhead from adding additional snapshots.

    However, I have just realized that even though they deleted everything
    in CVS and disabled CVS on that project entirely, I can still download a
    copy of the entire CVS repository to get my original code back. It is
    clearly documented in the CVS repository that the code is GPL and has
    my name in the copyright messages. Some of the code is clearly not
    compatible with current enhancements to ext2 (after my time, of course)
    so before people start using it again it would need to be cleaned up
    (e.g. get non-conflicting ext2 COMPAT feature bits, inode flags, ioctl
    numbers, space in the on-disk superblock, etc).

    It may also be possible to get the SF site admins to assign control
    of the SnapFS project to someone else if they are interested in
    working on this, because the current guys are off in proprietary-land,
    even though the original code was GPL. Sadly, I probably won't have
    any time to look at this in the near future, but maybe a few months
    down the road after I get settled into my new job.

    Cheers, Andreas
    --
    Andreas Dilger
    http://sourceforge.net/projects/ext2resize/
    http://www-mddsp.enel.ucalgary.ca/People/adilger/

    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2005-03-22 13:24    [W:3.420 / U:0.028 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site