Re: [PATCH v2 0/7] core.fsyncmethod: add 'batch' mode for faster fsyncing of multiple objects

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



"Neeraj K. Singh via GitGitGadget" <gitgitgadget@xxxxxxxxx> writes:

> V2 changes:
>
>  * Change doc to indicate that only some repo updates are batched

OK.

>  * Null and zero out control variables in do_batch_fsync under
>    unplug_bulk_checkin

OK.

>  * Make batch mode default on Windows.

I do not care either way ;-)

>  * Update the description for the initial patch that cleans up the
>    bulk-checkin infrastructure.

OK.

>  * Rebase onto 'seen' at 0cac37f38f9.

That's unfortunate.  Having to depend on almost everything in 'seen'
is a guaranteed way to ensure that the topic would never graduate to
'next'.

For this topic, ns/core-fsyncmethod is the only thing outside of
'master' that the previous round needed, so I did an equivalent of

    $ git checkout -b ns/batch-fsync b896f729e2
    $ git merge ns/core-fsyncmethod 

to prepare fd008b1442 and then queued the patches on top, i.e.

    $ git am -s mbox

> This work is based on 'seen' at . It's dependent on ns/core-fsyncmethod.

"at ."?

In any case, I've applied them on 0cac37f38f9 and then re-applied
the result on top of fd008b1442 (i.e. the same base as the previous
round was queued), which, with the magic of "am -3", applied
cleanly.  Double checking the result was also simple (i.e. the tip of
such an application on top of fd008b1442 can be merged with
0cac37f38f9 and the result should be identical to the result of
applying them directly on top of 0cac37f38f9) and seems to have
produced the right result.

\Thanks.





[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux