From: David Woodhouse <dwmw2@infradead.org> To: Bill Davidsen <davidsen@tmr.com> Cc: Yury Umanets <umka@namesys.com>, Daniel Egger <degger@fhm.edu>, Hans Reiser <reiser@namesys.com>, Nikita Danilov <Nikita@namesys.com>, Linux Kernel Mailinglist <linux-kernel@vger.kernel.org>, reiserfs mailing list <reiserfs-list@namesys.com> Subject: Re: Reiser4 status: benchmarked vs. V3 (and ext3) Date: Thu, 14 Aug 2003 14:58:28 +0100 [thread overview] Message-ID: <1060869508.4803.35.camel@passion.cambridge.redhat.com> (raw) In-Reply-To: <Pine.LNX.3.96.1030813160910.12417A-100000@gatekeeper.tmr.com> On Wed, 2003-08-13 at 21:12, Bill Davidsen wrote: > The driver should do the logical to physical mapping, but the portability > vanishes if the filesystem to physical mapping is not the same for all > machines and operating systems. For pluggable devices this is important. The portability also vanishes if the file system layout is not the same for all machines and operating systems... what's your point? Just like there are standard file systems, there are also standard 'translation layers' -- pseudofilesystems which are used to emulate a hard drive on flash storage -- and some of these are implemented for Linux. Take a PCMCIA flash card (real flash, not CF) with FTL and FAT on it, and it'll work just fine under both Windows and Linux, because they both use the standard FTL and FAT formats. FTL provides the logical<->physical mapping and the wear levelling, FAT is just normal FAT. > The leveling seems to be done by JFFs2 in a portable way, and that's as it > should be. You seem to be very confused here. JFFS2 works on flash directly; nothing's pretending to be a block device. It doesn't seem to be at all relevant to this discussion. JFFS2 does its own wear levelling and flash management, because it works directly on the flash. FAT can't do that -- it needs some other code (like the FTL code) to emulate a normal hard drive for it, providing wear levelling and logical<->physical translation for it. See http://www.infradead.org/~dwmw2/mtd-upper-layers.jpeg Wear levelling is not done in the driver -- the driver just drives the flash, and in fact is below the bottom of the diagram since it's largely irrelevant. It just gives you read/write/erase functions for the raw flash. Wear levelling is done either in the file system which works directly on the flash (JFFS2, YAFFS), or in the 'translation layer' which uses the flash to pretend to be a block device (FTL, NFTL, INFTL, SMTL). (In the case of the extremely naïve 'mtdblock' translation layer, no translation and no wear levelling is done at all.) > If the leveling were in the driver I don't believe even FAT > would work. I think that by 'driver' you actually mean the 'translation layer' or the combination of translation layer and underlying hardware driver, in which case you would be incorrect to say that it wouldn't work. That _is_ how it works, portably. -- dwmw2
WARNING: multiple messages have this Message-ID (diff)
From: David Woodhouse <dwmw2@infradead.org> To: Bill Davidsen <davidsen@tmr.com> Cc: Yury Umanets <umka@namesys.com>, Daniel Egger <degger@fhm.edu>, Hans Reiser <reiser@namesys.com>, Nikita Danilov <Nikita@namesys.com>, Linux Kernel Mailinglist <linux-kernel@vger.kernel.org>, reiserfs mailing list <reiserfs-list@namesys.com> Subject: Re: Reiser4 status: benchmarked vs. V3 (and ext3) Date: Thu, 14 Aug 2003 14:58:28 +0100 [thread overview] Message-ID: <1060869508.4803.35.camel@passion.cambridge.redhat.com> (raw) In-Reply-To: <Pine.LNX.3.96.1030813160910.12417A-100000@gatekeeper.tmr.com> On Wed, 2003-08-13 at 21:12, Bill Davidsen wrote: > The driver should do the logical to physical mapping, but the portability > vanishes if the filesystem to physical mapping is not the same for all > machines and operating systems. For pluggable devices this is important. The portability also vanishes if the file system layout is not the same for all machines and operating systems... what's your point? Just like there are standard file systems, there are also standard 'translation layers' -- pseudofilesystems which are used to emulate a hard drive on flash storage -- and some of these are implemented for Linux. Take a PCMCIA flash card (real flash, not CF) with FTL and FAT on it, and it'll work just fine under both Windows and Linux, because they both use the standard FTL and FAT formats. FTL provides the logical<->physical mapping and the wear levelling, FAT is just normal FAT. > The leveling seems to be done by JFFs2 in a portable way, and that's as it > should be. You seem to be very confused here. JFFS2 works on flash directly; nothing's pretending to be a block device. It doesn't seem to be at all relevant to this discussion. JFFS2 does its own wear levelling and flash management, because it works directly on the flash. FAT can't do that -- it needs some other code (like the FTL code) to emulate a normal hard drive for it, providing wear levelling and logical<->physical translation for it. See http://www.infradead.org/~dwmw2/mtd-upper-layers.jpeg Wear levelling is not done in the driver -- the driver just drives the flash, and in fact is below the bottom of the diagram since it's largely irrelevant. It just gives you read/write/erase functions for the raw flash. Wear levelling is done either in the file system which works directly on the flash (JFFS2, YAFFS), or in the 'translation layer' which uses the flash to pretend to be a block device (FTL, NFTL, INFTL, SMTL). (In the case of the extremely naïve 'mtdblock' translation layer, no translation and no wear levelling is done at all.) > If the leveling were in the driver I don't believe even FAT > would work. I think that by 'driver' you actually mean the 'translation layer' or the combination of translation layer and underlying hardware driver, in which case you would be incorrect to say that it wouldn't work. That _is_ how it works, portably. -- dwmw2
next prev parent reply other threads:[~2003-08-14 13:58 UTC|newest] Thread overview: 90+ messages / expand[flat|nested] mbox.gz Atom feed top 2003-07-23 21:02 Reiser4 status: benchmarked vs. V3 (and ext3) Hans Reiser 2003-07-24 4:26 ` Tupshin Harper 2003-07-24 4:31 ` Shawn 2003-07-24 4:56 ` Tupshin Harper 2003-07-24 5:21 ` Shawn 2003-07-24 5:33 ` Shawn 2003-07-24 11:10 ` Nikita Danilov 2003-07-24 15:10 ` Tupshin Harper 2003-07-24 15:26 ` Larry McVoy 2003-07-24 15:32 ` Tupshin Harper 2003-07-24 15:54 ` Larry McVoy 2003-08-01 16:15 ` Reiser4 and linux 2.6.0 Robert August Vincent II 2003-08-01 16:27 ` Tupshin Harper 2003-08-01 16:32 ` Nikita Danilov 2003-08-09 15:45 ` Hans Reiser 2003-08-10 2:02 ` Tupshin Harper 2003-08-10 12:30 ` Henning Westerholt 2003-08-11 11:25 ` Nikita Danilov 2003-08-01 17:16 ` Marcelo Pacheco 2003-08-01 16:29 ` Nikita Danilov 2003-08-02 0:11 ` Robert August Vincent II 2003-07-24 15:32 ` Reiser4 status: benchmarked vs. V3 (and ext3) Shawn 2003-07-24 15:33 ` Philippe Gramoullé 2003-07-24 15:47 ` Tupshin Harper 2003-07-24 15:57 ` Philippe Gramoullé 2003-07-24 16:24 ` Philippe Gramoullé 2003-07-24 16:01 ` Carl-Daniel Hailfinger 2003-07-24 16:08 ` Marcelo 2003-07-24 20:39 ` Tupshin Harper 2003-07-27 12:28 ` Hans Reiser 2003-07-27 12:45 ` Tomas Szepe 2003-07-27 14:01 ` Hans Reiser 2003-07-27 15:04 ` Gene Heskett 2003-07-27 22:07 ` Manuel Krause 2003-07-27 21:19 ` Manuel Krause 2003-07-24 15:59 ` Daniel Egger 2003-07-24 17:07 ` Nikita Danilov 2003-07-24 21:10 ` Tupshin Harper 2003-07-25 12:57 ` Nikita Danilov 2003-07-25 0:39 ` Daniel Egger 2003-07-25 13:02 ` Nikita Danilov 2003-07-25 14:20 ` Daniel Egger 2003-07-25 14:39 ` Yury Umanets 2003-07-26 1:08 ` Daniel Egger 2003-07-26 7:19 ` Yury Umanets 2003-07-26 14:13 ` Daniel Egger 2003-07-26 14:54 ` Yury Umanets 2003-07-26 15:21 ` Daniel Egger 2003-07-27 3:28 ` Valdis.Kletnieks 2003-07-27 10:30 ` Yury Umanets 2003-07-27 11:05 ` Daniel Egger 2003-07-27 11:46 ` Yury Umanets 2003-08-08 14:01 ` David Woodhouse 2003-08-08 14:01 ` David Woodhouse 2003-08-08 14:28 ` Bernd Eckenfels 2003-08-08 23:58 ` David Woodhouse 2003-08-09 0:29 ` Bernd Eckenfels 2003-08-09 0:38 ` David Woodhouse 2003-07-27 13:31 ` Hans Reiser 2003-07-27 14:13 ` Yury Umanets 2003-07-27 13:28 ` Hans Reiser 2003-07-27 14:10 ` Daniel Egger 2003-07-27 14:15 ` Yury Umanets 2003-08-13 20:12 ` Bill Davidsen 2003-08-14 5:04 ` Yury Umanets 2003-08-14 14:10 ` David Woodhouse 2003-08-15 11:15 ` Yury Umanets 2003-08-15 15:28 ` Bill Davidsen 2003-08-15 15:53 ` David Woodhouse 2003-08-14 13:58 ` David Woodhouse [this message] 2003-08-14 13:58 ` David Woodhouse 2003-07-27 15:30 ` Bernd Eckenfels 2003-07-27 15:49 ` Alan Cox 2003-08-08 13:23 ` David Woodhouse 2003-07-28 11:30 ` Hans Reiser 2003-09-10 8:29 ` myciel 2003-07-26 17:14 ` Jussi Laako 2003-07-27 13:35 ` Hans Reiser 2003-08-08 14:08 ` David Woodhouse 2003-07-27 12:59 ` Hans Reiser 2003-07-27 14:16 ` Daniel Egger 2003-07-27 15:32 ` Bernd Eckenfels 2003-08-08 14:29 ` David Woodhouse 2003-07-28 12:44 ` Hans Reiser 2003-07-28 13:06 ` Daniel Egger 2003-07-28 13:29 ` Hans Reiser 2003-07-28 13:48 ` Hans Reiser 2003-07-27 12:38 ` Hans Reiser 2003-07-26 8:33 ` Andrew Morton 2003-07-27 13:24 ` 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=1060869508.4803.35.camel@passion.cambridge.redhat.com \ --to=dwmw2@infradead.org \ --cc=Nikita@namesys.com \ --cc=davidsen@tmr.com \ --cc=degger@fhm.edu \ --cc=linux-kernel@vger.kernel.org \ --cc=reiser@namesys.com \ --cc=reiserfs-list@namesys.com \ --cc=umka@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: linkBe 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.