Hi Vyacheslav,
--- On Wed, 25/7/12, Vyacheslav Dubeyko <slava@xxxxxxxxxxx> wrote:
> Hi Hin-Tak,
>
> Sorry, I can see from the hfsplus code about what you are
> talking. You
> are right. The situation is clear for me. It needs to work.
> :-)
>
> Thank you for bug report.
>
> With the best regards,
> Vyacheslav Dubeyko.
I was going to confess that I might be using buggy code - it is rather a long history, but I am testing a port of netgear's HFS+ journalling change to current kernel. The long and short of the story is that Netgear contracted some company to add HFS+ support in 2010, which they released as a NAS product in 2011, and therefore posted a tar ball of modified 2.6.15 kernel source. This was worked on to port to 3.0-ish last summer, and I am moving it forward to 3.4.x-ish. Updating the journal shouldn't cause the kind of things I saw - even if it is done wrongly, I was hoping.
I am using 3.4.5/3.4.6, and indeed on special code branch and on journalled hfs+. It is an MBR disk.
I found that I can cause massive amount of problem by just untarring some big thing and then deleting the files one by one. (I did this with the netgear tar ball, which contains a kernel tree, and after comparing against a git checkout of the relevant version, delete identical files one by one from a list with a script).
i.e. try something similar to this:
tar -jxpvf kernel-tarball.tar.bz2 > somewhere_else/file-list
cat somewhere_else/file-list | perl -ne 'chomp; if (-f $_) {unlink $_;}'
On a separate but related note,
- there are 6 netgear tarballs, with 2 implementations of hfs+ journalling. i.e. there is a slightly newer hfs+ journalling from them since we checked last summer. The newer code copied the whole of /jbd/ from ext3 and renamed everything from jbd to hfsplus_jbd, etc and added some small HFS+-related things. Rather ugly, but possibly do something similiar as jbd does for ext3.
- there is a commercial/free-for-personal-use implementation of hfs+ support from a company Paragon, released last summer, for 2.6.38-. Doesn't build with current kernel; it is almost like nvidia/ATI's X 3D drivers - small glue code to build a kernel module against a binary-only archive library. (also Paragon's HFS+ product for windows seems to make a lot of mac users unhappy for corrupting data, but I might be doing some selective reading there :-))
- I have been looking at some random HFS+ disk images I have as well. One - the command line tools from xcode on apple's web site - is interesting in that the HFS+ volume header says it is over 400MB, but the file itself is only 180MB so obviously there is no secondary volume header (which is located at the end of volume). Or at least, not at the expected location. But Mac OS X does not have problem mounting it - there is only about 180MB worth of stuff inside.
I am thinking maybe for disk images, and also read-only mount, one should not need to check the secondary volume header, as this seems to be what Mac OS X is doing.
The interesting disk image is one of the command-line-tools from xcode on apple's web site (free registration). A few of them are compressed, which is at about 150MB, but one is 180MB, and shows what I wrote about, for those who wants to investigate.
Hin-Tak
> On Mon, 2012-07-23 at 23:35 +0400, Vyacheslav Dubeyko
> wrote:
> > Hi,
> >
> > On Jul 22, 2012, at 1:06 AM, Hin-Tak Leung wrote:
> >
> > >
> > > Correct - two interesting bugs. I thought I had
> supplied enough details for others to try to reproduce? The
> first is simply about deleting files, the latter about
> deleting files with extended attributes. So, to reproduce:
> > >
> > > 1. Have a hfs+ volume (created under Mac OS X
> would be better). Make sure it passed fsck.hfsplus (on
> linux).
> > > 2. copy the system Fonts folder (I think it is
> under /Library/Fonts) to it from Mac OS X. Font files have
> extended attributes, but other system files might do too.
> > > 3. Try to delete some of those files from Linux.
> > > 4. umount, run fsck.hfsplus on the volume. One
> would see:
> > >
> > > Executing fsck_hfs (version
> 540.1-Linux).
> > > ...
> > > ** Checking extents overflow file.
> > > Unused node is not erased (node =
> 1)
> > > ** Checking catalog file.
> > > Unused node is not erased (node =
> 18)
> > > ...
> > > ** Checking extended attributes file.
> > > Incorrect number of extended
> attributes
> > > (It should be 13 instead of 6)
> > > ...
> > > ** Repairing volume.
> > > RepairAttributesCheckABT: No
> matching catalog record found for id=438
> > > ...
> > > ** Rechecking volume.
> > > ...
> > > ** The volume journalled was repaired
> successfully.
> >
> > Currently, I can't reproduce these bugs. I think that I
> have not fully correct reproduction path. So, I have some
> questions.
> > What version of Linux kernel do you use? Or maybe do
> you have hfsplus file system driver code from special
> branch?
> >
> > I tried to reproduce these bugs on non-journaled hfs+
> volume, firstly, but without success. As I can see you use
> journaled hfs+ volume. Maybe the forced mount of journaled
> hfs+ was the reason of these bugs? By the way do you use MBR
> or GPT partitioned disk?
> >
> > >
> > > 'Unused node is not erased' & 'Incorrect
> number of extended attributes' were essentially what I wrote
> earlier. BTW, I ran fsck.hfsplus with:
> > >
> > > fsck.hfsplus -d -D 0x0033 -f
> > >
> > > - i.e. maximum amount of information, and have a
> look even if it appears to be clean. (there are -l, -y and
> -n switches to control whether fsck.hfsplus would actually
> fix anything found or leave it alone and just output info).
> > >
> > > The font folder is only about a few hundred MB, so
> one should be able to experiment with a small pen drive and
> do byte-level comparisons to see what fsk.hfsplus is not
> happy about and what does it change - although I am sure
> looking at diskdev_cmds's source would also be useful. I
> just happen to want the font folder for other things I do.
> > >
> > >
> > > --
> > > To unsubscribe from this list: send the line
> "unsubscribe linux-fsdevel" in
> > > the body of a message to majordomo@xxxxxxxxxxxxxxx
> > > More majordomo info at http://vger.kernel.org/majordomo-info.html
> >
> > With the best regards,
> > Vyacheslav Dubeyko.
> >
> > --
> > To unsubscribe from this list: send the line
> "unsubscribe linux-fsdevel" in
> > the body of a message to majordomo@xxxxxxxxxxxxxxx
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
