From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Woodhouse To: dedekind@infradead.org In-Reply-To: <1106399029.29388.50.camel@sauron.oktetlabs.ru> References: <20050119152427.GB26711@wohnheim.fh-wedel.de> <20050119153233.GD26711@wohnheim.fh-wedel.de> <6934efce050121144619d2899d@mail.gmail.com> <1106399029.29388.50.camel@sauron.oktetlabs.ru> Content-Type: text/plain Date: Sat, 22 Jan 2005 22:04:13 +0000 Message-Id: <1106431453.6932.57.camel@localhost.localdomain> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Cc: MTD List Subject: Re: JFFS3 & performance List-Id: Linux MTD discussion mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , On Sat, 2005-01-22 at 16:03 +0300, Artem B. Bityuckiy wrote: > 2. Worse, compression impacts JFFS2 design globally. You know, that the > maximum amount of data JFFS2 may store in one inode node is the size of > RAM page, most often 4K. > > Q: Why we restrict ourself with this size? > A: Because of compression. It's not just compression that restricts us to 4KiB. Compressing in larger chunks isn't hard -- zisofs does it, for example. The real problem is the larger buffers you need for garbage collection. It's not impossible to fix that though. We've always intended to have a per-inode attribute for user-specified compression parameters; the most basic of which would be 'no compression'. I originally intended to expose those as attributes in the way that 'chattr' works, with an ioctl on the file -- but I suspect xattrs would be a better approach nowadays. Compression has other drawbacks though -- if you throw out compression you can do fixed-size records, you can have a block-based architecture and simplify your metadata, ... -- dwmw2