From: Matthias Schniedermeyer <ms@citd.de>
To: Oleg Drokin <green@namesys.com>
Cc: Tomas Szepe <szepe@pinerecords.com>,
Ivan Gyurdiev <ivg2@cornell.edu>,
Andreas Dilger <adilger@clusterfs.com>,
linux-kernel@vger.kernel.org
Subject: Re: reiserfs4
Date: Thu, 7 Aug 2003 18:31:14 +0200 [thread overview]
Message-ID: <20030807163114.GA1699@citd.de> (raw)
In-Reply-To: <20030807142544.GF20639@namesys.com>
On Thu, Aug 07, 2003 at 06:25:44PM +0400, Oleg Drokin wrote:
> Hello!
>
> On Thu, Aug 07, 2003 at 04:23:12PM +0200, Matthias Schniedermeyer wrote:
> > > > There is sort of "universal" fs convertor for linux that can convert almost
> > > > any fs to almost any other fs.
> > > > The only requirement seems to be that both fs types should have read/write support in Linux.
> > > > http://tzukanov.narod.ru/convertfs/
> > > I'm afraid I cannot recommend using this tool.
> > > A test conversion from reiserfs to ext3 (inside a vmware machine)
> > > screwed up the data real horrorshow: directory structure seems
> > > ok but file contents are apparently shifted.
> > That answers the question that poped up in my mind.
> > "How does the tool know where the blocks are, and in which order it can
> > 'move' then without corrupting the data.(*)
>
> Well, there is FIBMAP ioctl that does this.
>
> > Seems it doesn't know it.
>
> It does. And our tests were more succesful, I believe.
>
> > But it is possibel(*2) to do what the programm wants to do, you only
> > have to find out the order in which you have to copy the blocks to
> > prevent garbage. That's all the magic.
>
> Sure.
Ups. Seems i am wrong, i "grep"ed for FIBMAP and the tool uses it. So i
guess the tool should be able to do everything correctly.
I take everything back and claim the opposite. :-)
(german idiom. "Ich nehm alles zurueck und behaupte das Gegenteil")
Bis denn
--
Real Programmers consider "what you see is what you get" to be just as
bad a concept in Text Editors as it is in women. No, the Real Programmer
wants a "you asked for it, you got it" text editor -- complicated,
cryptic, powerful, unforgiving, dangerous.
next prev parent reply other threads:[~2003-08-07 16:31 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-08-07 1:05 reiserfs4 Vladimir Lazarenko
2003-08-07 5:02 ` reiserfs4 Andreas Dilger
2003-08-07 5:12 ` reiserfs4 Ivan Gyurdiev
2003-08-07 7:27 ` reiserfs4 Oleg Drokin
2003-08-07 13:21 ` reiserfs4 Tomas Szepe
2003-08-07 14:23 ` reiserfs4 Matthias Schniedermeyer
2003-08-07 14:25 ` reiserfs4 Oleg Drokin
2003-08-07 16:31 ` Matthias Schniedermeyer [this message]
2003-08-07 14:34 ` reiserfs4 Nikita Danilov
2003-08-07 15:01 ` reiserfs4 mdew
2003-08-08 13:05 ` reiserfs4 Hans Reiser
2003-08-08 16:23 ` reiserfs4 Tomas Szepe
2003-08-07 15:20 ` reiserfs4 Ivan Gyurdiev
2003-08-07 10:00 ` reiserfs4 Michael Buesch
2003-08-07 14:00 ` reiserfs4 Hans Reiser
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=20030807163114.GA1699@citd.de \
--to=ms@citd.de \
--cc=adilger@clusterfs.com \
--cc=green@namesys.com \
--cc=ivg2@cornell.edu \
--cc=linux-kernel@vger.kernel.org \
--cc=szepe@pinerecords.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox