From mboxrd@z Thu Jan 1 00:00:00 1970 From: Sergei Antonov Subject: Re: A few thoughts on hfsplus dev (Re: [PATCH v2] hfsplus: add journal replay) Date: Fri, 28 Mar 2014 14:42:39 +0100 Message-ID: References: <1395616538.43957.YahooMailBasic@web172305.mail.ir2.yahoo.com> <1395729058.2197.3.camel@slavad-CELSIUS-H720> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8BIT Cc: "htl10@users.sourceforge.net" , "linux-fsdevel@vger.kernel.org" , Al Viro , Christoph Hellwig , Andrew Morton To: Vyacheslav Dubeyko Return-path: Received: from mail-oa0-f44.google.com ([209.85.219.44]:51077 "EHLO mail-oa0-f44.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752265AbaC1Nmj convert rfc822-to-8bit (ORCPT ); Fri, 28 Mar 2014 09:42:39 -0400 Received: by mail-oa0-f44.google.com with SMTP id n16so6144152oag.31 for ; Fri, 28 Mar 2014 06:42:39 -0700 (PDT) In-Reply-To: <1395729058.2197.3.camel@slavad-CELSIUS-H720> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On 25 March 2014 07:30, Vyacheslav Dubeyko wrote: > On Tue, 2014-03-25 at 02:37 +0100, Sergei Antonov wrote: > >> > I would also have >> > preferred that you point out exactly where Vyacheslav's work went wrong, and supply >> > a patch on top, instead of starting your own. If you want credit for it, I hope you can >> > arrange with Vyacheslav to swap the order of signed-off, for one or more of the merged patches, >> > for example. In any case, while I am happy to see your work, and am willing to review it, >> > you have not convinced me to try your work out yet. So. >> >> I am ready for further convincing efforts. >> Though now that Vyacheslav has stopped replying in the thread there is no progress. Two compromises have been suggested by me in the thread, I'll recap them here for you or anyone who wasn't following. >> 1. Since collecting all transactions requires more memory (up to 12 MB in my tests, but theoretically more), I suggested a threshold. Let's say it will be 1 MB. Once collected data reaches one meg, flush it, free the buffers and go on collecting. >> 2. A very simple suggestions that makes my logic closer to Vyacheslav's one-by-one transaction processing approach. In case we encounter a corrupted transaction, replay (good) transactions collected so far. Corrupted transaction is a rare thing (caused by cosmic rays!), but partial replay looks sane and not a big change to the code. >> > > It doesn't make sense for me to repeat the same statements again and > again. > > I have such principal points: > (1) On-disk layout declarations should live in peace with Technical Note > TN1150; > (2) Journal replay should be transaction based. Could you clarify "transaction based"? Seriously. Because since there are transactions in HFS+ journal, all replay implementations are transaction-based in a way.