From mboxrd@z Thu Jan 1 00:00:00 1970 From: Hin-Tak Leung Subject: Re: [PATCH 00/14] hfsplus: introduce journal replay functionality Date: Sun, 19 Jan 2014 01:50:41 +0000 (GMT) Message-ID: <1390096241.23321.YahooMailBasic@web172302.mail.ir2.yahoo.com> Reply-To: htl10@users.sourceforge.net Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: Andrew Morton , Linux FS devel list To: slava@dubeyko.com Return-path: Received: from nm12-vm0.bullet.mail.ird.yahoo.com ([77.238.189.196]:20332 "EHLO nm12-vm0.bullet.mail.ird.yahoo.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751700AbaASB5I convert rfc822-to-8bit (ORCPT ); Sat, 18 Jan 2014 20:57:08 -0500 Sender: linux-fsdevel-owner@vger.kernel.org List-ID: ------------------------------ On Thu, Jan 9, 2014 06:12 GMT Vyacheslav Dubeyko wrote: >Hi Hin-Tak, > >On Thu, 2013-12-26 at 14:26 -0800, Andrew Morton wrote: >> On Thu, 26 Dec 2013 15:57:45 +0000 (GMT) Hin-Tak Leung wrote: >>=20 >> > It is quite a co-incidence - I have also spent some hours in the l= ast few days rebasing the netgear derived patch set bit-rotting in my h= ard disk. I have a quick diff and it seems that you have drawn some ide= as but yours is largely an independent effort. Anyway, here are a few t= hings from where I am.=20 >> >=20 >> > - It appears that you don't treat the special files (catalog, etc)= special? netgear's does; but i think there is a mistake in that they d= on't consider them ever getting fragmented, so they were not journaling= those files properly.=20 >> >=20 >> > - I am still nowhere near figuring out what's the issue with just = runing du on one funny volume i have. The driver gets confused after a = few du's but the disk always fsck clean.=20 >> >=20 >> > - I see I still have one out-standing patch not yet submitted - th= e one about folder counts on case-sensitive volumes.=20 >> >=20 >> > I'll try to spend some time reading your patches and maybe even tr= y them out. Will write again.=20 >>=20 >> Thanks, useful! >>=20 >> Vyacheslav, I'll duck the patchset pending Hin-Tak's review.=A0 Plea= se >> cc me on the later resend. > >How do you feel about the patchset? What opinion do you have? Could yo= u >share your opinion about patchset? Tested-by: Hin-Tak Leung I have given the patch set a bit of light usage, and it fsck'ed clean a= fterwards. So that's the minimum it should do.I also see that you have spent subst= antial amount of effort in verifying and checking the validity and sanity of t= he journal itself (which Netgear certainly didn't do). And thanks for the good wor= k! That part at least is very desirable and overdue and should land in the kernel so= on. About documentation and the new "norecovery" option. Should "norecovery= " imply read-only (and also state clearly so)? The meaning of the "force"= option also needs some updating - if we play back journal, then unclean journa= lled volumes would be mounted read-write after verify/validating and journal= playback, correct? I see there is a need for "norecovery" in addition to "read-on= ly" (in the typical convention elsewhere, the latter will occasionally write to a journalle= d fs, in the case of journal playback - so "norecovery" is "really no write, = not a single byte, I mean it, don't even playback journal"), but I think no= recovery should imply read-only, unless in combination with "force"? A somewhat minor thing - I see a few instances of 'pr_err("journal replay is failed\n");' - the "is" isn't needed. Just E= nglish usage. Now it still worries me that whichever way we implements journalling in= the linux kernel, it may be correct according to spec, but doesn't inter-op with Apple's. This is especially relevant since a substantial portion of use= rs who wants hfs+ journalling in their linux kernel is because they have a= n intel Mac and they are dual-booting. Now we have 3 implementations - ap= ple's, this, and Netgear's. Even if we discount Netgear's, while each of them=20 will create a journal during its normal mode of operation, will playbac= k a journal of its own creation, we really need to test the case of playback of jou= rnals made by the Mac OS X darwin kernel... because I can think of this happe= ning: somebody has a dual-boot machine, you pull the plug while it is in Mac = OS X, and the boot-loader is configured to go into linux by default after a s= hort time-out (or vice versa). So again, I must thank you for spending the effort on verifying and val= idating the journal entries. On separate/somewhat unrelated matters, I came across this bug report i= n the recent activities: https://bugs.launchpad.net/ubuntu/+source/hfsprogs/+bug/680606 I think we addressed both of the 2nd and 3rd entries: errors ("Invalid volume file count", "Invalid volume free block coun= t") error ("Unused node is not erased") The first entry looks suspiciously like the problem which I have/had: (restore a large directory from time-machine) Invoke "rm -r" targeting the directory - segfault occurs - Various applications freeze, and it's impossible to cleanly shut d= own - OS X Disk Utility reports that the disk can't be repaired So the disk I manually edited and fixed, still can get the kernel confu= sed (i.e the kernel just get confused, if one unmount and reboot, the disk is fs= ck-clean still), just by repeatedly running "du". I found that I need to put the system = under some memory stress: I can run "du" for a dozen of times on an idle syst= em freshly rebooted, but as soon as I have google-chrome running with a fe= w browser windows opening (or mozilla/firefox). The kernel driver can get confuse= d if one transverse the file system quickly (with a du, or in the above case, with an r"m -= rf large directory"), especially the system is relatively loaded. Oh, there is still the folder count issue with case-sensitive HFS+ (whi= ch AFAIK, just a convenience for some file system transversal usage, not actually of any= critical function), but that's a relatively harmless issue. We can deal with it at some poi= nt. Regards, Hin-Tak -- 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