All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Woodhouse <dwmw2@infradead.org>
To: jffs-dev@axis.com, bjorn.wesen@axis.com
Cc: mtd@infradead.org, linux@handhelds.org, nico@cam.org
Subject: JFFS2 Request For Testing.
Date: Thu, 22 Feb 2001 19:08:14 +0000	[thread overview]
Message-ID: <8382.982868894@redhat.com> (raw)

I've got JFFS2 to the stage where it's passing dbench runs and the GC looks
reasonably OK. The design is basically the result of the discussion we were
having a few weeks ago (on the jffs-dev list) - I don't think anything's
particularly different from what we were talking about. 

Please take a look and comment, and preferably test it. Instructions on 
getting it from CVS are on http://www.linux-mtd.infradead.org/ and it'll 
turn up in ftp.uk.linux.org:/pub/people/dwmw2/mtd/cvs at about 11pm tonight.

For easy testing on a PC, turn on CONFIG_MTD_MTDRAM and test it on ram, 
instead of real flash.

There's free beer for the first person who tells me why I need the 
invalidate_inode_pages() in jffs2_file_release() when no other filesystem 
seems to need it, or why it sometimes gets stuck on unmount, in 
__wait_on_page() called from invalidate_inodes(). I suspect they're 
related, and it's a stupid bug on my part.

There's also a free beer for whoever provides mkfs.jffs2.

Aside from the bugs, there's a few things left to tidy up...

 - background GC
 - fine-tune the allocation / GC thresholds
 - More optimal compression. Currently it's optimised for mips32 code.
 - chattr support - turning on/off and tuning compression per-inode
 - checkpointing
 - making the scan code populate real inodes so read_inode just after 
	mount doesn't have to read the flash twice for large files.
 - disable compression in commit_write()?
 - stop it depending on a block device. mount(8) needs a change for this.
 - test, test, test
 - make it work on NAND flash. We need to know when we can GC
	deletion dirents, etc. And think about holes/truncation. It can
	all be done reasonably simply, but it need implementing.
 - NAND flash will require new dirent/dnode structures on the medium with
	ECC data in rather than just the CRC we're using ATM.
 - more?

--
dwmw2




To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

                 reply	other threads:[~2001-02-22 19:09 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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=8382.982868894@redhat.com \
    --to=dwmw2@infradead.org \
    --cc=bjorn.wesen@axis.com \
    --cc=jffs-dev@axis.com \
    --cc=linux@handhelds.org \
    --cc=mtd@infradead.org \
    --cc=nico@cam.org \
    /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.