[RFC PATCH 0/7] bottom-up ns/batched-fsync & "plugging" in object-file.c

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

 



This RFC series is a continuation of the thread at
https://lore.kernel.org/git/CANQDOde2OG8fVSM1hQE3FBmzWy5FkgQCWAUYhFztB8UGFyJELg@xxxxxxxxxxxxxx/;
More details in individual commit messages.

I'd suggested (upthread of) there pass new object flags down to the
object machinery instead of the {un,}plug_bulk_checkin() API
route. This has advantages described in more details in individual
patches.

This also shows that the not-using tmpdir approach can be
significantly faster than using it, and per my understanding just as
safe fsync-wise for those willing to deal with the caveat of possibly
having truncated *unreachable* objects.

I thought that showing some working code with what I was suggesting
was more productive than continuing the current back & forth :)

Ævar Arnfjörð Bjarmason (7):
  write-or-die.c: remove unused fsync_component() function
  unpack-objects: add skeleton HASH_N_OBJECTS{,_{FIRST,LAST}} flags
  object-file: pass down unpack-objects.c flags for "bulk" checkin
  update-index: use a utility function for stdin consumption
  update-index: pass down an "oflags" argument
  update-index: rename "buf" to "line"
  update-index: make use of HASH_N_OBJECTS{,_{FIRST,LAST}} flags

 builtin/add.c            |  3 --
 builtin/unpack-objects.c | 62 ++++++++++++++------------
 builtin/update-index.c   | 96 ++++++++++++++++++++++++++--------------
 bulk-checkin.c           | 86 -----------------------------------
 bulk-checkin.h           |  6 ---
 cache.h                  |  9 ++--
 object-file.c            | 39 +++++++++++-----
 t/t1050-large.sh         |  3 ++
 write-or-die.c           |  7 ---
 9 files changed, 131 insertions(+), 180 deletions(-)

-- 
2.35.1.1428.g1c1a0152d61




[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