* logfs: max 4K writepage size
@ 2011-09-04 10:20 srimugunthan dhandapani
2011-09-07 6:56 ` Jörn Engel
0 siblings, 1 reply; 4+ messages in thread
From: srimugunthan dhandapani @ 2011-09-04 10:20 UTC (permalink / raw)
To: Jörn Engel, linux-mtd, linux-fsdevel
Hi,
>
>> While i still have your attention, i would like to point out at max
>> writepage size restriction in logfs. Currently logfs has a max
>> writepage size as 4K. Currently, large page nand flashes and MLC nand
>> come in 8K page sizes. As the usecase for logfs is large nand
>> flashes(mostly with parallel and DMA write capabilities), it may be
>> essential to remove the 4K write page size restriction.
>> I was only able to change the logfs-tools for >4K writepage size. If
>> you send a patch, that makes logfs useable for writepagesize >4K, i
>> can try on real hardware, instead of nandsim and give you the results
>> :-)
>
> That sure sounds useful. I'll have a look...
>
> Jörn
If you plan to do this, when can we expect your patches in the kernel?
Can you suggest what changes have to be done to have >4K writepage size.
From what i looked, it doesnt seem straight forward. I think the 4K
writepage size restriction is because
the flash device is memory mapped for caching purposes.
Initially, I wouldnt want to have the caching feature. Is there some
code in the ancient logfs tree
(http://git.kernel.org/?p=linux/kernel/git/joern/ancient_logfs.git;a=summary)
without the device mapping, that i can make use of?
Thanks,
mugunthan
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 4+ messages in thread* Re: logfs: max 4K writepage size 2011-09-04 10:20 logfs: max 4K writepage size srimugunthan dhandapani @ 2011-09-07 6:56 ` Jörn Engel 2011-09-07 17:30 ` srimugunthan dhandapani 0 siblings, 1 reply; 4+ messages in thread From: Jörn Engel @ 2011-09-07 6:56 UTC (permalink / raw) To: srimugunthan dhandapani; +Cc: linux-fsdevel, linux-mtd On Sun, 4 September 2011 15:50:03 +0530, srimugunthan dhandapani wrote: > > If you plan to do this, when can we expect your patches in the kernel? Don't expect me to predict the future - my past predictions have not proven to be very reliable. > Can you suggest what changes have to be done to have >4K writepage size. I think the only change strictly necessary is the patch below, removing an assertion. Plus the second patch below for mklogfs. > From what i looked, it doesnt seem straight forward. I think the 4K > writepage size restriction is because > the flash device is memory mapped for caching purposes. > Initially, I wouldnt want to have the caching feature. Careful. I know that for some devices the caching makes a performance difference somewhere between 100x and 1000x. Pretty much whenever you encounter a crap FTL on your random USB stick, SDcard, etc. that is the case. So if you want to avoid caching for your purposes, you'd have to do it in a way that doesn't cause a huge performance regression to these devices. In other words, caching needs to stay in the code, but be made contingent on some condition that I couldn't specify in half an hour. As the result - having both caching and non-caching code, plus some decision heuristic - will be a non-trivial maintenance burden, there should also be a non-trivial performance benefit attached. But then again, I suppose the two patches below mean you won't even attempt going non-caching anyway. :) Jörn -- Unless something dramatically changes, by 2015 we'll be largely wondering what all the fuss surrounding Linux was really about. -- Rob Enderle [PATCH] logfs: remove useless BUG_ON It prevents write sizes >4k. Signed-off-by: Joern Engel <joern@logfs.org> --- fs/logfs/journal.c | 1 - 1 files changed, 0 insertions(+), 1 deletions(-) diff --git a/fs/logfs/journal.c b/fs/logfs/journal.c index 9da2970..1e1c369 100644 --- a/fs/logfs/journal.c +++ b/fs/logfs/journal.c @@ -612,7 +612,6 @@ static size_t __logfs_write_je(struct super_block *sb, void *buf, u16 type, if (len == 0) return logfs_write_header(super, header, 0, type); - BUG_ON(len > sb->s_blocksize); compr_len = logfs_compress(buf, data, len, sb->s_blocksize); if (compr_len < 0 || type == JE_ANCHOR) { memcpy(data, buf, len); -- 1.7.2.3 [PATCH] Allow larger write shift Current flashes with 8k write size already exist. Why pick 16? No good reason, it's a bit bigger and will do for a while. Maybe 32 or 64 would be sane choices - beyond 64 is definitely insane - but until someone can properly argue where exactly the boundary should be, this is good enough for a while. Signed-off-by: Joern Engel <joern@logfs.org> --- mkfs.c | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/mkfs.c b/mkfs.c index fd54b75..138067a 100644 --- a/mkfs.c +++ b/mkfs.c @@ -514,8 +514,8 @@ static void mkfs(struct super_block *sb) fail("segment shift must be larger than block shift"); if (blockshift != 12) fail("blockshift must be 12"); - if (writeshift > 12) - fail("writeshift too large (max 12)"); + if (writeshift > 16) + fail("writeshift too large (max 16)"); sb->segsize = 1 << segshift; sb->blocksize = 1 << blockshift; sb->blocksize_bits = blockshift; -- 1.7.2.3 ______________________________________________________ Linux MTD discussion mailing list http://lists.infradead.org/mailman/listinfo/linux-mtd/ ^ permalink raw reply related [flat|nested] 4+ messages in thread
* Re: logfs: max 4K writepage size 2011-09-07 6:56 ` Jörn Engel @ 2011-09-07 17:30 ` srimugunthan dhandapani 2011-09-07 19:17 ` Jörn Engel 0 siblings, 1 reply; 4+ messages in thread From: srimugunthan dhandapani @ 2011-09-07 17:30 UTC (permalink / raw) To: Jörn Engel; +Cc: linux-mtd, linux-fsdevel On Wed, Sep 7, 2011 at 12:26 PM, Jörn Engel <joern@logfs.org> wrote: > >> Can you suggest what changes have to be done to have >4K writepage size. > > I think the only change strictly necessary is the patch below, > removing an assertion. Plus the second patch below for mklogfs. > Thanks for the patches. I was able to do basic mount-copy-unmount once. Let me test more with multiple mount unmount cycles and see if there are problems. I think we have to give mklogfs /dev/mtdblock0 instead of /dev/mtd0 I updated wikipedia with steps to use logfs http://en.wikipedia.org/wiki/LogFS thanks, mugunthan -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: logfs: max 4K writepage size 2011-09-07 17:30 ` srimugunthan dhandapani @ 2011-09-07 19:17 ` Jörn Engel 0 siblings, 0 replies; 4+ messages in thread From: Jörn Engel @ 2011-09-07 19:17 UTC (permalink / raw) To: srimugunthan dhandapani; +Cc: linux-mtd, linux-fsdevel On Wed, 7 September 2011 23:00:30 +0530, srimugunthan dhandapani wrote: > > I was able to do basic mount-copy-unmount once. > Let me test more with multiple mount unmount cycles and see if there > are problems. I'm always happy when I can fix bugs. Though not always happy to discover that the d*ckhead who created them was me. > I think we have to give mklogfs /dev/mtdblock0 instead of /dev/mtd0 You can use mtd0 instead of /dev/mtd0, similar to jffs2. Any /dev/foo gets interpreted by some common code in the kernel. As it's not a block device, mount fails. mtd0 doesn't start with /dev/, so it must be special somehow and gets passed to the filesystem. Jffs2 and logfs are can then do something with this string. And yes, this sounds really stupid. Having /dev/mtd0 do the right thing would certainly be less confusing than the current state. > I updated wikipedia with steps to use logfs > http://en.wikipedia.org/wiki/LogFS Cool! Thanks! Jörn -- Schrödinger's cat is <BLINK>not</BLINK> dead. -- Illiad -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2011-09-07 19:17 UTC | newest] Thread overview: 4+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2011-09-04 10:20 logfs: max 4K writepage size srimugunthan dhandapani 2011-09-07 6:56 ` Jörn Engel 2011-09-07 17:30 ` srimugunthan dhandapani 2011-09-07 19:17 ` Jörn Engel
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).