All of lore.kernel.org
 help / color / mirror / Atom feed
From: btinsley <btinsley@gmail.com>
To: reiserfs-list@namesys.com
Subject: Re: online fsck
Date: Fri, 27 May 2005 18:04:20 -0500	[thread overview]
Message-ID: <263a8b350505271604186263f@mail.gmail.com> (raw)
In-Reply-To: <4297A43C.1010608@slaphack.com>

> I'd rather donate for a reiser4 online repacker.  By the time
> something's fsck'd, so to speak, I'd rather take it offline and possibly
> pull in backups.  But a repacker (even an offine one) and a resizer
> (even an offline one) are two things that we even have in the Linux
> ntfs-tools, and it's also something that people would have an immediate
> use for.

Pulling in backups is not always practical though. It's no fun
restoring a 900GB filesystem from tape, especially when the data has
to be transferred over the network :-)

I would like to see the repacker though. I have certain filesystems
that could really use it. Would it be practical to have an option to
enable the repacker to include some level of consistency checking?
It's been my experience that corruptions requiring a rebuild-tree are
pretty obvious to reiserfsck ;-)

> 
> Another killer feature would be to bring back metadata, or at least a
> way to create special (plugin) files, and the ability to write certain
> kinds of userland plugins, thus giving us FS-level support for things
> like zipfiles.  Yet another killer feature would be stable crypto and
> compression, and the ability to enable it only for certain directories.

I would go for this one as well. Our particular application stores
data in an industry-standard format. Being able to
index/search/crypt/etc. this at the FS level would let me get rid of
the cost and overhead of Oracle :-)

  reply	other threads:[~2005-05-27 23:04 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-05-23 18:24 online fsck btinsley
2005-05-24 10:43 ` E.Gryaznova
2005-05-24 23:26   ` marco
2005-05-25  3:02     ` btinsley
2005-05-27  6:15       ` marco
2005-05-27  9:17       ` Philippe Gramoullé
2005-05-27  9:32         ` Yiannis Mavroukakis
2005-05-27 14:12           ` mjt
2005-05-27 22:50           ` David Masover
2005-05-27 23:04             ` btinsley [this message]
2005-05-28  7:58     ` Vladimir Saveliev
     [not found] <20040422150042.5b49c6c3.pegasus@nerv.eu.org>
2004-04-22 13:34 ` Chris Mason
2004-04-22 14:24   ` Jure Pečar
2004-04-22 15:24     ` Chris Dukes
2004-04-22 15:45       ` Nikita Danilov
2004-04-22 15:58         ` Marcelo Pacheco
2004-04-22 17:11         ` Chris Dukes
2004-04-22 17:51   ` Hans Reiser
2004-04-22 18:06     ` Chris Mason
2004-04-22 18:14       ` Hans Reiser
2004-04-22 18:15     ` Chris Dukes
2004-04-25 14:10       ` daniel.poelzleithner
2004-04-22 23:20 ` Matthias Andree

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=263a8b350505271604186263f@mail.gmail.com \
    --to=btinsley@gmail.com \
    --cc=reiserfs-list@namesys.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.