[PATCH v2 00/15] hfsplus: introduce journal replay functionality

[PATCH v2 00/15] hfsplus: introduce journal replay functionality

[Vyacheslav Dubeyko]

Hi,

This second version of patchset that implements journal replay
functionality in HFS+ file system driver.

v1->v2
* Fix error messages incorrectness (Hin-Tak Leung)
* Fix issue with remount "mount -o remount,rw <device> <folder>"
* Rework "force" and "norecovery" mount options support (Hin-Tak Leung)

Technical Note TN1150:
"The purpose of the journal is to ensure that when a group of
 related changes are being made, that either all of those changes
 are actually made, or none of them are made. This is done by
 gathering up all of the changes, and storing them in a separate
 place (in the journal). Once the journal copy of the changes is
 completely written to disk, the changes can actually be written
 to their normal locations on disk. If a failure happens at that
 time, the changes can simply be copied from the journal to their
 normal locations. If a failure happens when the changes are being
 written to the journal, but before they are marked complete, then
 all of those changes are ignored."

"A group of related changes is called a transaction. When all of
 the changes of a transaction have been written to their normal
 locations on disk, that transaction has been committed, and is
 removed from the journal. The journal may contain several
 transactions. Copying changes from all transactions to their
 normal locations on disk is called replaying the journal."

"In order to replay the journal, an implementation just loops
 over the transactions, copying each individual block in the
 transaction from the journal to its proper location on the
 volume. Once those blocks have been flushed to the media
 (not just the driver!), it may update the journal header to
 remove the transactions."

"Here are the steps to replay the journal:
  1. Read the volume header into variable vhb. The volume may
     have an HFS wrapper; if so, you will need to use it to
     determine the location of the volume header.
  2. Test the kHFSVolumeJournaledBit in the attributes field of
     the volume header. If it is not set, there is no journal
     to replay, and you are done.
  3. Read the journal info block from the allocation block number
     vhb.journalInfoBlock, into variable jib.
  4. If kJIJournalNeedsInitMask is set in jib.flags, the journal
     was never initialized, so there is no journal to replay.
  5. Verify that kJIJournalInFSMask is set and kJIJournalOnOtherDeviceMask
     is clear in jib.flags.
  6. Read the journal header at jib.offset bytes from the start
     of the volume, and place it in variable jhdr.
  7. If jhdr.start equals jhdr.end, the journal does not have
     any transactions, so there is nothing to replay.
  8. Set the current offset in the journal (typically a local
     variable) to the start of the journal buffer, jhdr.start.
  9. While jhdr.start does not equal jhdr.end, perform the
     following steps:
       1. Read a block list header of jhdr.blhdr_size bytes from
          the current offset in the journal into variable blhdr.
       2. For each block in bhdr.binfo[1] to bhdr.binfo[blhdr.num_blocks],
          inclusive, copy bsize bytes from the current offset in
          the journal to sector bnum on the volume (to byte offset
          bnum*jdhr.jhdr_size). Remember that jhdr_size is the
          size of a sector, in bytes.
       3. If bhdr.binfo[0].next is zero, you have completed the
          last block list of the current transaction; set jhdr.start
          to the current offset in the journal."

It was reworked concept of "force" mount option. It is used to force
write access to volumes that are marked as locked, only. This option
doesn't work for journaled volumes with non-empty journal. HFS+ drive
tries to replay journal and ignores forcing write access in the case of
journal replay failure. It is possible to access HFS+ volume in
read-only mode only for such case. The "force" option is ignored
for the case of "norecovery" option request also.

With the best regards,
Vyacheslav Dubeyko.
---

 Documentation/filesystems/hfsplus.txt |   16 +-
 fs/hfsplus/Makefile                   |    3 +-
 fs/hfsplus/hfsplus_fs.h               |   33 +-
 fs/hfsplus/hfsplus_raw.h              |   53 +-
 fs/hfsplus/journal.c                  | 1215 +++++++++++++++++++++++++++++++++
 fs/hfsplus/options.c                  |   17 +-
 fs/hfsplus/part_tbl.c                 |    4 +-
 fs/hfsplus/super.c                    |  105 ++-
 fs/hfsplus/wrapper.c                  |   28 +-
 9 files changed, 1435 insertions(+), 39 deletions(-)
-- 
1.7.9.5

Re: [PATCH v2 00/15] hfsplus: introduce journal replay functionality

[Hin-Tak Leung]

--------------------------------------------
On Fri, 24/1/14, Vyacheslav Dubeyko <slava@dubeyko.com> wrote:

 Subject: [PATCH v2 00/15] hfsplus: introduce journal replay functionality
 To: "Linux FS devel list" <linux-fsdevel@vger.kernel.org>
 Cc: "Al Viro" <viro@zeniv.linux.org.uk>, "ChristophHellwig" <hch@infradead.org>, "Hin-Tak Leung" <htl10@users.sourceforge.net>, "Andrew Morton" <akpm@linux-foundation.org>
 Date: Friday, 24 January, 2014, 15:25
 
 Hi,
 
 This second version of patchset that implements journal
 replay
 functionality in HFS+ file system driver.
 
 v1->v2
 * Fix error messages incorrectness (Hin-Tak Leung)
 * Fix issue with remount "mount -o remount,rw <device>
 <folder>"
 * Rework "force" and "norecovery" mount options support
 (Hin-Tak Leung)
 
 Technical Note TN1150:
 "The purpose of the journal is to ensure that when a group
 of
  related changes are being made, that either all of those
 changes
  are actually made, or none of them are made. This is done
 by
  gathering up all of the changes, and storing them in a
 separate
  place (in the journal). Once the journal copy of the
 changes is
  completely written to disk, the changes can actually be
 written
  to their normal locations on disk. If a failure happens at
 that
  time, the changes can simply be copied from the journal to
 their
  normal locations. If a failure happens when the changes are
 being
  written to the journal, but before they are marked
 complete, then
  all of those changes are ignored."
 
 "A group of related changes is called a transaction. When
 all of
  the changes of a transaction have been written to their
 normal
  locations on disk, that transaction has been committed, and
 is
  removed from the journal. The journal may contain several
  transactions. Copying changes from all transactions to
 their
  normal locations on disk is called replaying the journal."
 
 "In order to replay the journal, an implementation just
 loops
  over the transactions, copying each individual block in
 the
  transaction from the journal to its proper location on the
  volume. Once those blocks have been flushed to the media
  (not just the driver!), it may update the journal header
 to
  remove the transactions."
 
 "Here are the steps to replay the journal:
   1. Read the volume header into variable vhb. The
 volume may
      have an HFS wrapper; if so, you
 will need to use it to
      determine the location of the
 volume header.
   2. Test the kHFSVolumeJournaledBit in the attributes
 field of
      the volume header. If it is not
 set, there is no journal
      to replay, and you are done.
   3. Read the journal info block from the allocation
 block number
      vhb.journalInfoBlock, into variable
 jib.
   4. If kJIJournalNeedsInitMask is set in jib.flags,
 the journal
      was never initialized, so there is
 no journal to replay.
   5. Verify that kJIJournalInFSMask is set and
 kJIJournalOnOtherDeviceMask
      is clear in jib.flags.
   6. Read the journal header at jib.offset bytes from
 the start
      of the volume, and place it in
 variable jhdr.
   7. If jhdr.start equals jhdr.end, the journal does
 not have
      any transactions, so there is
 nothing to replay.
   8. Set the current offset in the journal (typically a
 local
      variable) to the start of the
 journal buffer, jhdr.start.
   9. While jhdr.start does not equal jhdr.end, perform
 the
      following steps:
        1. Read a block list header
 of jhdr.blhdr_size bytes from
           the current offset in the
 journal into variable blhdr.
        2. For each block in
 bhdr.binfo[1] to bhdr.binfo[blhdr.num_blocks],
           inclusive, copy bsize
 bytes from the current offset in
           the journal to sector
 bnum on the volume (to byte offset
           bnum*jdhr.jhdr_size).
 Remember that jhdr_size is the
           size of a sector, in
 bytes.
        3. If bhdr.binfo[0].next is
 zero, you have completed the
           last block list of the
 current transaction; set jhdr.start
           to the current offset in
 the journal."
 
 It was reworked concept of "force" mount option. It is used
 to force
 write access to volumes that are marked as locked, only.
 This option
 doesn't work for journaled volumes with non-empty journal.
 HFS+ drive
 tries to replay journal and ignores forcing write access in
 the case of
 journal replay failure. It is possible to access HFS+ volume
 in
 read-only mode only for such case. The "force" option is
 ignored
 for the case of "norecovery" option request also.
 
 With the best regards,
 Vyacheslav Dubeyko.
 ---
 
  Documentation/filesystems/hfsplus.txt |   16
 +-
  fs/hfsplus/Makefile         
          |    3 +-
  fs/hfsplus/hfsplus_fs.h         
      |   33 +-
  fs/hfsplus/hfsplus_raw.h         
     |   53 +-
  fs/hfsplus/journal.c         
         | 1215
 +++++++++++++++++++++++++++++++++
  fs/hfsplus/options.c         
         |   17 +-
  fs/hfsplus/part_tbl.c         
        |    4 +-
  fs/hfsplus/super.c           
         |  105 ++-
  fs/hfsplus/wrapper.c         
         |   28 +-
  9 files changed, 1435 insertions(+), 39 deletions(-)
 -- 
 1.7.9.5
 
Thanks, Vyacheslav, for presisting on this.

I'll give the new patchset a try at somepoint.

About inter-operability, I thought of one idea - it would be useful to
wrap genuine OS X code around some kind of fuse framework to run
under linux? I don't know how difficult it is, but at some point I think
besides the specification (tn1150, we need to look at the actual
implementation for inter-operability anyhow.

The fs code in the OS X kernel is under the xnu component, in the bsd layer,
I seem to remember.

Another left-over issue I forgot to mention again: some disk images
(I came across one, one of the xcode devtool download from Apple - so it is
"official", not some random 3rd party who did broken things) have
the secondary header at a slightly different offset from the end. The details
I don't have in hand but I believe I posted the details publicly at some stage -
possibly at the redhat bugzilla(!).

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

Re: [PATCH v2 00/15] hfsplus: introduce journal replay functionality

[Vyacheslav Dubeyko]

Hi Hin-Tak,

> On 27 янв. 2014 г., at 8:22, Hin-Tak Leung <htl10@users.sourceforge.net> wrote:
> 
> About inter-operability, I thought of one idea - it would be useful to
> wrap genuine OS X code around some kind of fuse framework to run
> under linux? I don't know how difficult it is, but at some point I think
> besides the specification (tn1150, we need to look at the actual
> implementation for inter-operability anyhow.

I don't think that it makes sense. First of all, it can be really time-consuming task. From another point of view, it will be really slow solution. And I don't think that it will be simple to port this code base from one ideology to another. Moreover, it is not interesting task for me personally. :)

> 
> The fs code in the OS X kernel is under the xnu component, in the bsd layer,
> I seem to remember.
> 
> Another left-over issue I forgot to mention again: some disk images
> (I came across one, one of the xcode devtool download from Apple - so it is
> "official", not some random 3rd party who did broken things) have
> the secondary header at a slightly different offset from the end. The details
> I don't have in hand but I believe I posted the details publicly at some stage -
> possibly at the redhat bugzilla(!).
> 

As I remember correctly, we had discussion about this issue. I tried to reproduce such situation but without any success. Every volume is created by mkfs utility. So, if it is impossible to create volume with such anomalous layout then it is a volume corruption. Could you share the way of creation such HFS+ volume?

Thanks,
Vyacheslav Dubeyko.

--
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

Re: [PATCH v2 00/15] hfsplus: introduce journal replay functionality

[Hin-Tak Leung]

--------------------------------------------
On Mon, 27/1/14, Vyacheslav Dubeyko <slava@dubeyko.com> wrote:

 Subject: Re: [PATCH v2 00/15] hfsplus: introduce journal replay functionality
 To: "htl10@users.sourceforge.net" <htl10@users.sourceforge.net>
 Cc: "Linux FS devel list" <linux-fsdevel@vger.kernel.org>, "Al Viro" <viro@zeniv.linux.org.uk>, "ChristophHellwig" <hch@infradead.org>, "Andrew Morton" <akpm@linux-foundation.org>
 Date: Monday, 27 January, 2014, 13:25
 
 Hi Hin-Tak,
 
 > On 27 янв. 2014 г., at 8:22, Hin-Tak Leung <htl10@users.sourceforge.net>
 wrote:
 > 
 > About inter-operability, I thought of one idea - it
 would be useful to
 > wrap genuine OS X code around some kind of fuse
 framework to run
 > under linux? I don't know how difficult it is, but at
 some point I think
 > besides the specification (tn1150, we need to look at
 the actual
 > implementation for inter-operability anyhow.
 
 I don't think that it makes sense. First of all, it can be
 really time-consuming task. From another point of view, it
 will be really slow solution. And I don't think that it will
 be simple to port this code base from one ideology to
 another. Moreover, it is not interesting task for me
 personally. :)
 
 > 
 > The fs code in the OS X kernel is under the xnu
 component, in the bsd layer,
 > I seem to remember.
 > 
 > Another left-over issue I forgot to mention again: some
 disk images
 > (I came across one, one of the xcode devtool download
 from Apple - so it is
 > "official", not some random 3rd party who did broken
 things) have
 > the secondary header at a slightly different offset
 from the end. The details
 > I don't have in hand but I believe I posted the details
 publicly at some stage -
 > possibly at the redhat bugzilla(!).
 > 
 
 As I remember correctly, we had discussion about this issue.
 I tried to reproduce such situation but without any success.
 Every volume is created by mkfs utility. So, if it is
 impossible to create volume with such anomalous layout then
 it is a volume corruption. Could you share the way of
 creation such HFS+ volume?
 
 Thanks,
 Vyacheslav Dubeyko.
 
Hi  Vyacheslav,

About the fuse-based HFS+ project - I agree it will be time-consuming,
and yes, it is probably going to be slow; but there is no better option
in terms of compatibility if you use genuine apple code (or part thereof)!
At least, the apple code is worth some reading - and it being under 
an open license, there is no reason not to keep it in mind as a possible
source of reference.

The context and details of the slightly off secondary volume header
is captured in the thread:
http://permalink.gmane.org/gmane.linux.file-systems/66405
so I shall not repeat. It is useful to remind myself details I have forgotten!

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

Re: [PATCH v2 00/15] hfsplus: introduce journal replay functionality

[Andrew Morton]

On Fri, 24 Jan 2014 19:25:18 +0400 Vyacheslav Dubeyko <slava@dubeyko.com> wrote:

> This second version of patchset that implements journal replay
> functionality in HFS+ file system driver.

The series introduces a lot of build glitches on i386 (and other 32-bit
builds)

- tons of printk mismatch warnings

- unresolvable references to __udivdi3 and __umoddi3 (need to use
  do_div() or similar).

- several bisection holes:

  - with 4 patches applied, error: implicit declaration of function 'JHDR_SIZE'

  - with three patches applied, warning: 'hfsplus_create_journal' used but never defined

and probably others.

I'll drop the series for now.  Please, find an i386 compiler and ensure
that we get a clean build at every point of the patch series.


To find the __udivdi3 thing I do something like

	make M=fs/hfsplus
	grep __udivdi3 fs/hfsplus/*.o

then for the offending .o file

	make fs/hfsplus/foo.s (or foo.lst)

then poke around in the assembly code to locate the offending function.

Re: [PATCH v2 00/15] hfsplus: introduce journal replay functionality

[Vyacheslav Dubeyko]

On Wed, 2014-02-05 at 15:48 -0800, Andrew Morton wrote:
> On Fri, 24 Jan 2014 19:25:18 +0400 Vyacheslav Dubeyko <slava@dubeyko.com> wrote:
> 
> > This second version of patchset that implements journal replay
> > functionality in HFS+ file system driver.
> 
> The series introduces a lot of build glitches on i386 (and other 32-bit
> builds)
> 
> - tons of printk mismatch warnings
> 
> - unresolvable references to __udivdi3 and __umoddi3 (need to use
>   do_div() or similar).
> 
> - several bisection holes:
> 
>   - with 4 patches applied, error: implicit declaration of function 'JHDR_SIZE'
> 
>   - with three patches applied, warning: 'hfsplus_create_journal' used but never defined
> 
> and probably others.
> 
> I'll drop the series for now.  Please, find an i386 compiler and ensure
> that we get a clean build at every point of the patch series.
> 
> 
> To find the __udivdi3 thing I do something like
> 
> 	make M=fs/hfsplus
> 	grep __udivdi3 fs/hfsplus/*.o
> 
> then for the offending .o file
> 
> 	make fs/hfsplus/foo.s (or foo.lst)
> 
> then poke around in the assembly code to locate the offending function.

Ok. Thank you. I'll check patchset building on i386 platform and I'll
fix all found errors.

Thanks,
Vyacheslav Dubeyko.

Re: [PATCH v2 00/15] hfsplus: introduce journal replay functionality

[Vyacheslav Dubeyko]

Hi Andrew,

On Thu, 2014-02-06 at 10:21 +0400, Vyacheslav Dubeyko wrote:
> On Wed, 2014-02-05 at 15:48 -0800, Andrew Morton wrote:
> > On Fri, 24 Jan 2014 19:25:18 +0400 Vyacheslav Dubeyko <slava@dubeyko.com> wrote:
> > 
> > > This second version of patchset that implements journal replay
> > > functionality in HFS+ file system driver.
> > 
> > The series introduces a lot of build glitches on i386 (and other 32-bit
> > builds)
> > 
> > - tons of printk mismatch warnings
> > 
> > - unresolvable references to __udivdi3 and __umoddi3 (need to use
> >   do_div() or similar).
> > 
> > - several bisection holes:
> > 
> >   - with 4 patches applied, error: implicit declaration of function 'JHDR_SIZE'
> > 
> >   - with three patches applied, warning: 'hfsplus_create_journal' used but never defined
> > 

I've reproduced (1) printk mismatch warnings; and (2) unresolvable
references to __udivdi3 and __umoddi3 build issues. But I am unable to
reproduce the issue with JHDR_SIZE and hfsplus_create_journal. And I
assume that I misunderstand something. This declarations live inside of
journal.c file only. And I add journal.c file in Makefile in
0015-hfsplus-integrate-journal-replay-support-into-driver.patch only.
So, how do you achieve build issues with JHDR_SIZE and
hfsplus_create_journal? Could you share your way? Maybe do you use some
special compilation options or additional tools during build?

Thanks,
Vyacheslav Dubeyko.

Re: [PATCH v2 00/15] hfsplus: introduce journal replay functionality

[Andrew Morton]

On Fri, 07 Feb 2014 10:05:44 +0400 Vyacheslav Dubeyko <slava@dubeyko.com> wrote:

> Hi Andrew,
> 
> On Thu, 2014-02-06 at 10:21 +0400, Vyacheslav Dubeyko wrote:
> > On Wed, 2014-02-05 at 15:48 -0800, Andrew Morton wrote:
> > > On Fri, 24 Jan 2014 19:25:18 +0400 Vyacheslav Dubeyko <slava@dubeyko.com> wrote:
> > > 
> > > > This second version of patchset that implements journal replay
> > > > functionality in HFS+ file system driver.
> > > 
> > > The series introduces a lot of build glitches on i386 (and other 32-bit
> > > builds)
> > > 
> > > - tons of printk mismatch warnings
> > > 
> > > - unresolvable references to __udivdi3 and __umoddi3 (need to use
> > >   do_div() or similar).
> > > 
> > > - several bisection holes:
> > > 
> > >   - with 4 patches applied, error: implicit declaration of function 'JHDR_SIZE'
> > > 
> > >   - with three patches applied, warning: 'hfsplus_create_journal' used but never defined
> > > 
> 
> I've reproduced (1) printk mismatch warnings; and (2) unresolvable
> references to __udivdi3 and __umoddi3 build issues. But I am unable to
> reproduce the issue with JHDR_SIZE and hfsplus_create_journal. And I
> assume that I misunderstand something. This declarations live inside of
> journal.c file only. And I add journal.c file in Makefile in
> 0015-hfsplus-integrate-journal-replay-support-into-driver.patch only.
> So, how do you achieve build issues with JHDR_SIZE and
> hfsplus_create_journal? Could you share your way? Maybe do you use some
> special compilation options or additional tools during build?

Nope, just i386 "make allmodconfig ; make fs/hfsplus/journal.o".

Apply these:

hfsplus-add-necessary-declarations-for-journal-replay
hfsplus-rework-hfsplus_submit_bio-method
hfsplus-implement-init-destroy-journal-object-functionality
hfsplus-implement-functionality-for-hfsplus_journal_need_init-flag

get this:

fs/hfsplus/journal.c: In function 'hfsplus_create_journal':
fs/hfsplus/journal.c:186: error: implicit declaration of function 'JHDR_SIZE'
fs/hfsplus/journal.c: In function 'hfsplus_init_journal':
fs/hfsplus/journal.c:244: warning: format '%lu' expects type 'long unsigned int', but argument 2 has type 'sector_t'
fs/hfsplus/journal.c:259: warning: format '%lu' expects type 'long unsigned int', but argument 2 has type 'sector_t'
fs/hfsplus/journal.c:264: warning: format '%lu' expects type 'long unsigned int', but argument 2 has type 'sector_t'
fs/hfsplus/journal.c:282: warning: format '%lu' expects type 'long unsigned int', but argument 2 has type 'sector_t'
fs/hfsplus/journal.c:290: warning: format '%lu' expects type 'long unsigned int', but argument 2 has type 'sector_t'

z:/usr/src/25> grep JHDR_SIZE include/linux/*.h
z:/usr/src/25> grep JHDR_SIZE fs/hfsplus/*.[ch]
fs/hfsplus/journal.c:#define HFSPLUS_DEFAULT_JHDR_SIZE  (4 * 1024)
fs/hfsplus/journal.c:           jnl->jh->jhdr_size = cpu_to_le32(HFSPLUS_DEFAULT_JHDR_SIZE);
fs/hfsplus/journal.c:   jnl->jh->start = cpu_to_le64(JHDR_SIZE(jnl->jh));
fs/hfsplus/journal.c:   jnl->jh->end = cpu_to_le64(JHDR_SIZE(jnl->jh));

Re: [PATCH v2 00/15] hfsplus: introduce journal replay functionality

[Hin-Tak Leung]

--------------------------------------------
On Fri, 7/2/14, Vyacheslav Dubeyko <slava@dubeyko.com> wrote:

 Subject: Re: [PATCH v2 00/15] hfsplus: introduce journal replay functionality
 To: "Andrew Morton" <akpm@linux-foundation.org>
 Cc: "Linux FS devel list" <linux-fsdevel@vger.kernel.org>, "Al Viro" <viro@zeniv.linux.org.uk>, "ChristophHellwig" <hch@infradead.org>, "Hin-Tak Leung" <htl10@users.sourceforge.net>
 Date: Friday, 7 February, 2014, 6:05
 
 Hi Andrew,
 
 On Thu, 2014-02-06 at 10:21 +0400, Vyacheslav Dubeyko
 wrote:
 > On Wed, 2014-02-05 at 15:48 -0800, Andrew Morton
 wrote:
 > > On Fri, 24 Jan 2014 19:25:18 +0400 Vyacheslav
 Dubeyko <slava@dubeyko.com>
 wrote:
 > > 
 > > > This second version of patchset that
 implements journal replay
 > > > functionality in HFS+ file system driver.
 > > 
 > > The series introduces a lot of build glitches on
 i386 (and other 32-bit
 > > builds)
 > > 
 > > - tons of printk mismatch warnings
 > > 
 > > - unresolvable references to __udivdi3 and
 __umoddi3 (need to use
 > >   do_div() or similar).
 > > 
 > > - several bisection holes:
 > > 
 > >   - with 4 patches applied, error:
 implicit declaration of function 'JHDR_SIZE'
 > > 
 > >   - with three patches applied,
 warning: 'hfsplus_create_journal' used but never defined
 > > 
 
 I've reproduced (1) printk mismatch warnings; and (2)
 unresolvable
 references to __udivdi3 and __umoddi3 build issues. But I am
 unable to
 reproduce the issue with JHDR_SIZE and
 hfsplus_create_journal. And I
 assume that I misunderstand something. This declarations
 live inside of
 journal.c file only. And I add journal.c file in Makefile
 in
 0015-hfsplus-integrate-journal-replay-support-into-driver.patch
 only.
 So, how do you achieve build issues with JHDR_SIZE and
 hfsplus_create_journal? Could you share your way? Maybe do
 you use some
 special compilation options or additional tools during
 build?
 
 Thanks,
 Vyacheslav Dubeyko.
 
Hi Vyacheslav,

I came across this patch (http://marc.info/?l=linux-fsdevel&m=138446099500610&w=2)
about an earlier __divdi3 issue - the analysis is quite thorough and I think relevant
for the __udivdi3 / __umoddi3 issues. Hope this helps.

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

Re: [PATCH v2 00/15] hfsplus: introduce journal replay functionality

[Vyacheslav Dubeyko]

Hi Hin-Tak,

On Tue, 2014-02-11 at 07:29 +0000, Hin-Tak Leung wrote:
>  
> Hi Vyacheslav,
> 
> I came across this patch (http://marc.info/?l=linux-fsdevel&m=138446099500610&w=2)
> about an earlier __divdi3 issue - the analysis is quite thorough and I think relevant
> for the __udivdi3 / __umoddi3 issues. Hope this helps.
> 

Thank you. I have fixed these issues. I don't fix all warnings yet. I am
simply preparing patch sequence without any warning. Unfortunately, I
haven't enough time for it.

Thanks,
Vyacheslav Dubeyko.