Re: ReiserFS on a flash device?
On Mon, Jul 28, 2003 at 08:53:57AM +0400, Yury Umanets wrote: On Mon, 2003-07-28 at 06:33, Mike Fedyk wrote: On Sun, Jul 27, 2003 at 02:55:31PM +0400, Yury Umanets wrote: Default journal size is too big (32MB) for usual embedded device. I mean, that flash is expensive and it is pity to loss 32MB for journal :) What? You mean it isn't reduced in size based on block device size like with ext3? Yes, is isn't. Use reiserfstune to make it smaller. Well I'm glad to hear it's possible to use ReiserFS on small devices, but I think that requiring a kernel patch, or a GRUB patch, to handle different journal sizes is not good. Are there plans to have the kernel and GRUB detect it at runtime? -- ___Shawn T. Rutledge (_ | |_) [EMAIL PROTECTED] * http://ecloud.org:8080 __) | | \
Re: ReiserFS on a flash device?
On Mon, 2003-07-28 at 11:05, Shawn Rutledge wrote: On Mon, Jul 28, 2003 at 08:53:57AM +0400, Yury Umanets wrote: On Mon, 2003-07-28 at 06:33, Mike Fedyk wrote: On Sun, Jul 27, 2003 at 02:55:31PM +0400, Yury Umanets wrote: Default journal size is too big (32MB) for usual embedded device. I mean, that flash is expensive and it is pity to loss 32MB for journal :) What? You mean it isn't reduced in size based on block device size like with ext3? Yes, is isn't. Use reiserfstune to make it smaller. Well I'm glad to hear it's possible to use ReiserFS on small devices, but I think that requiring a kernel patch, or a GRUB patch, to handle different journal sizes is not good. Are there plans to have the kernel and GRUB detect it at runtime? Support for non-standard journal is merged to kernel recently. Use last pre or wait until next stable kernel is released. GRUB is able to with with it too. Use ftp://ftp.namesys.com/pub/misc-patches/grub-0.93-reiserfs-non-standard-journal.diff for that. Regards. -- We're flying high, we're watching the world passes by...
reiserfsck question
hi there! i have a situation here. my system is linux 2.4.19 with reiserfs 3.6. when i want to check the FS (single root partition) from usual environment i get the following cloud9:~ # reiserfsck /dev/hda2 reiserfsck 3.6.2 (2002) Will read-only check consistency of the filesystem on /dev/hda2 Will put log info to 'stdout' Do you want to run this program?[N/Yes] (note need to type Yes):Yes ### reiserfsck --check started at Mon Jul 28 11:47:24 2003 ### Device /dev/hda2 is mounted w/ write permissions, can not check it when i boot single mode i try the same command, but this time it says that --fix-fixable is ignored (because of RO partition?) the question is the following: how should i correctly run the fsck to get my FS with errors fixed? follwing is the part from the syslog Jul 28 11:48:55 cloud9 kernel: vs-7000: search_by_entry_key: search_by_key returned item position == 04vs-7000: search_by_entry_key: search_by_key returned item position == 04vs-7000: search_by_entry_key: search_by_key returned item position == 04vs-7000: search_by_entry_key: search_by_key returned item position == 04vs-7000: search_by_entry_key: search_by_key returned item position == 04vs-7000: search_by_entry_key: search_by_key returned item position == 04vs-7000: search_by_entry_key: search_by_key returned item position == 04vs-7000: search_by_entry_key: search_by_key returned item position == 04vs-7000: search_by_entry_key: search_by_key returned item position == 04vs-7000: search_by_entry_key: search_by_key returned item position == 04vs-7000: search_by_entry_key: search_by_key returned item position == 04vs-7000: search_by_entry_key: search_by_key returned item position == 04vs-7000: search_by_entry_key: search_by_key returned item position == 04vs-7000: search_by_entry_key: sea Jul 28 11:49:48 cloud9 kernel: ch_by_key returned item position == 04vs-7000: search_by_entry_key: search_by_key returned item position == 04vs-7000: search_by_entry_key: search_by_key returned item position == 04vs-7000: search_by_entry_key: search_by_key returned item position == 04vs-7000: search_by_entry_key: search_by_key returned item position == 04vs-7000: search_by_entry_key: search_by_key returned item position == 04vs-7000: search_by_entry_key: search_by_key returned item position == 04vs-7000: search_by_entry_key: search_by_key returned item position == 04vs-7000: search_by_entry_key: search_by_key returned item position == 04vs-7000: search_by_entry_key: search_by_key returned item position == 04vs-7000: search_by_entry_key: search_by_key returned item position == 04vs-7000: search_by_entry_key: search_by_key returned item position == 04vs-7000: search_by_entry_key: search_by_key returned item position == 04vs-7000: search_by_entry_key: search_by_key returned item position hoping to get your answer asap, as this is a production server. thank you in advance Vladimir Sopot http://photofile.ru project manager
Re: Reiser4 status: benchmarked vs. V3 (and ext3)
Daniel Egger wrote: Are you sure CF cards have wear leveling? I'm pretty confident that they have defect sector management but no wear leveling. There's a huge difference between those two. I am told that they do by flx. After all, they are most used for the FAT filesystem. -- Hans
Re: Reiser4 status: benchmarked vs. V3 (and ext3)
Daniel Egger wrote: Am Son, 2003-07-27 um 14.59 schrieb Hans Reiser: I thought that close was fine, it was putting it in the same block that was the problem? This looks fine for normal harddrives put on flash you'd probably like to write the data evenly over the free space in some already formatted section still leaving the oportunity to format some other sectors to not run out of space. I was not able to parse the sentence above.;-) Again, I think this is best solved in the device layer. A device layer that shuffles around sectors would have interesting semantics, like hardly being portable because one would have to use exactly the same device driver with the same parameters to use the filesystem and thus retrieve the data. No, you could be more clever than that. -- Hans
Re: Reiser4 status: benchmarked vs. V3 (and ext3)
Am Mon, 2003-07-28 um 14.44 schrieb Hans Reiser: This looks fine for normal harddrives put on flash you'd probably like to write the data evenly over the free space in some already formatted section still leaving the oportunity to format some other sectors to not run out of space. I was not able to parse the sentence above.;-) s/put/but/ As already mentioned the flash chips have to be erased before they can be written. The erasesize is much larger than the typical block size which means that although a block doesn't contain valid data it still contains something which means that it cannot be written until it was erased. That's why JFFS2 is using garbage collection to reclaim unused but (at the moment) unusable space. No, you could be more clever than that. Sure. :) -- Servus, Daniel signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: Reiser4 status: benchmarked vs. V3 (and ext3)
So, in summary, reiser4 will do a good job of flushing in large batches using large bios, and that is most of what you can do to optimize for large erase size. Things that could be added: improved compression for small files, garbage collection based freeing of unused blocks, increasing node size to equal erase size. We can add such features for a fee, or you can code them yourself and send us a patch. If I am wrong about compact flashes all having hardware wear leveling so that FAT can be used on them, then you can add wear leveling to the list of features desirable. -- Hans
Autoconf error
Hi! I am trying to compile reiser4progs from bk; I run 'prepare' and get this output $ ./prepare Running aclocal... Running autoheader... Running autoconf... configure.in:44: error: possibly undefined macro: dnl If this token and others are legitimate, please use m4_pattern_allow. See the Autoconf documentation. configure.in:48: error: possibly undefined macro: AC_CHECK_LIB configure.in:49: error: possibly undefined macro: AC_MSG_ERROR configure.in:54: error: possibly undefined macro: AC_CHECK_HEADER configure.in:58: error: possibly undefined macro: AC_MSG_CHECKING configure.in:60: error: possibly undefined macro: AC_TRY_LINK_FUNC configure.in:61: error: possibly undefined macro: AC_MSG_RESULT configure.in:73: error: possibly undefined macro: AC_TRY_RUN then run configure and get: $ ./configure checking build system type... i686-pc-linux checking host system type... i686-pc-linux checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking whether make sets $(MAKE)... yes checking for working aclocal-1.4... found checking for working autoconf... found checking for working automake-1.4... found checking for working autoheader... found checking for working makeinfo... found ./configure: line 1827: syntax error near unexpected token `;;' ./configure: line 1827: `;;' $ autoconf --version autoconf (GNU Autoconf) 2.57 any ideas?
