From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eric Nelson Date: Sun, 20 Mar 2016 08:02:33 -0700 Subject: [U-Boot] ext4 and caching In-Reply-To: <20160319154227.GB4983@localhost.localdomain> References: <56E9A92F.5000205@nelint.com> <20160319154227.GB4983@localhost.localdomain> Message-ID: <56EEBB89.7000406@nelint.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Thanks Ioan, On 03/19/2016 08:42 AM, Ioan Nicu wrote: > Hi Eric, > > On Wed, Mar 16, 2016 at 11:42:55AM -0700, EXT Eric Nelson wrote: >> Hi all, >> >> I've been seeing the same sort of issues repoted by Ionut >> and as addressed by this patch: >> http://lists.denx.de/pipermail/u-boot/2014-January/171459.html >> >> That patch was added in commit fc0fc50 and reverted in commit 715b56f. >> >> It no longer applies cleanly, and when I tried to resurrect it, >> I saw errors traversing directories and perhaps something went >> wrong with my merge. >> >> Ionut, do you have a current version of this patch? >> > > We reverted that patch because it was breaking ext4 write support. I initially > developed the patch on top of an older u-boot which didn't have write supoort > at all. > > I have tried to refactor my patch to work with both read/write, but I gave up > when I saw that the ext4 write code relied on the old behavior of > read_allocated_block/ext4fs_get_extent_block. I could have worked around that, > but then the whole thing would have looked like hack, so I didn't like it ... > > If you are interested in a current version of this patch, I could try to > revive it. But it has the limitation I mentioned above, so I guess you could > use it just for some ext4 read performance measurement test. > I do want to get rid of the performance problem, but as I suggested by my patch set, I think that a more general-purpose cache is a better approach. Regards, Eric