{"thread":{"id":"63666","subject":"git only writing 4k at a time","startedAt":"2025-06-18T20:59:04Z","lastAt":"2025-07-01T11:58:19Z","messageCount":3,"participants":["Haylin Moore","brian m. carlson","Patrick Steinhardt"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"520368","messageId":"CALnKHDCH_174KnP6Um+G8YCpDBGNNk40xS0T2K6VtnDv9hE37Q@mail.gmail.com","threadId":"63666","inReplyTo":null,"subject":"git only writing 4k at a time","fromName":"Haylin Moore","fromEmail":"hmoore@qumulo.com","sentAt":"2025-06-18T20:58:52Z","receivedAt":"2025-06-18T20:59:04Z","isPatch":false,"sender":{"key":"hmoore@qumulo.com","avatar":null},"body":"Hiya list,\n\nI've been investigating some performance issues around git clones over\nnetwork mounts. We have noticed that git is only writing 4k at a time.\nThese small serial writes are making it such that even though each\nwrite is only a 3ms operation, the total time balloons. Looking around\nthe source code I found that reftable_writer is initialized by default\n(though I cannot find the block_size argument being supplied in my\ncursory look) always to DEFAULT_BLOCK_SIZE (4096). Is there some way\nto increase/configure this block size such that larger writes happen?\nIn git/Documentation/config/reftable.adoc this block size is mentioned\nin a manner that almost feels configurable, but I'm not sure if this\nis just internal for development.\n\nThanks,\n~ Haylin Moore\n"},{"id":"520376","messageId":"aFM9Uh0K2TSAuoHb@fruit.crustytoothpaste.net","threadId":"63666","inReplyTo":"CALnKHDCH_174KnP6Um+G8YCpDBGNNk40xS0T2K6VtnDv9hE37Q@mail.gmail.com","subject":"Re: git only writing 4k at a time","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2025-06-18T22:27:30Z","receivedAt":"2025-06-18T22:27:38Z","isPatch":false,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"On 2025-06-18 at 20:58:52, Haylin Moore wrote:\n> Hiya list,\n> \n> I've been investigating some performance issues around git clones over\n> network mounts. We have noticed that git is only writing 4k at a time.\n> These small serial writes are making it such that even though each\n> write is only a 3ms operation, the total time balloons. Looking around\n> the source code I found that reftable_writer is initialized by default\n> (though I cannot find the block_size argument being supplied in my\n> cursory look) always to DEFAULT_BLOCK_SIZE (4096). Is there some way\n> to increase/configure this block size such that larger writes happen?\n> In git/Documentation/config/reftable.adoc this block size is mentioned\n> in a manner that almost feels configurable, but I'm not sure if this\n> is just internal for development.\n\nIt's fine to adjust reftable.blockSize upwards if you'd like, which\ncontrols the block size for reftable writes (which is what you're seeing\nif the writes are from the reftable code).  I think at least some\nversions of JGit use 64 KiB for various reasons.\n\nAs the documentation describes, there may be some performance penalties\nduring reads since more refs will have to be read, so reading a single\nref will likely be more expensive.  However, you may find that\nacceptable and you can adjust the values such that they provide the\nright balance in your environment.  I would definitely recommend a\npower-of-two block size, though.\n-- \nbrian m. carlson (they/them)\nToronto, Ontario, CA\n"},{"id":"521019","messageId":"aGPNVRxZQiFpCIFs@pks.im","threadId":"63666","inReplyTo":"aFM9Uh0K2TSAuoHb@fruit.crustytoothpaste.net","subject":"Re: git only writing 4k at a time","fromName":"Patrick Steinhardt","fromEmail":"ps@pks.im","sentAt":"2025-07-01T11:58:13Z","receivedAt":"2025-07-01T11:58:19Z","isPatch":false,"sender":{"key":"ps@pks.im","avatar":"https://avatars.githubusercontent.com/u/4056630?v=4"},"body":"On Wed, Jun 18, 2025 at 10:27:30PM +0000, brian m. carlson wrote:\n> On 2025-06-18 at 20:58:52, Haylin Moore wrote:\n> > Hiya list,\n> > \n> > I've been investigating some performance issues around git clones over\n> > network mounts. We have noticed that git is only writing 4k at a time.\n> > These small serial writes are making it such that even though each\n> > write is only a 3ms operation, the total time balloons. Looking around\n> > the source code I found that reftable_writer is initialized by default\n> > (though I cannot find the block_size argument being supplied in my\n> > cursory look) always to DEFAULT_BLOCK_SIZE (4096). Is there some way\n> > to increase/configure this block size such that larger writes happen?\n> > In git/Documentation/config/reftable.adoc this block size is mentioned\n> > in a manner that almost feels configurable, but I'm not sure if this\n> > is just internal for development.\n> \n> It's fine to adjust reftable.blockSize upwards if you'd like, which\n> controls the block size for reftable writes (which is what you're seeing\n> if the writes are from the reftable code).  I think at least some\n> versions of JGit use 64 KiB for various reasons.\n\nYup. The default block size of 4kB was picked because most filesystems\nuse it. Google uses 64kB because to the best of my knowledge they use\nSpanner to store the tables? At least that's what I recall from past\nconversations.\n\n> As the documentation describes, there may be some performance penalties\n> during reads since more refs will have to be read, so reading a single\n> ref will likely be more expensive.  However, you may find that\n> acceptable and you can adjust the values such that they provide the\n> right balance in your environment.  I would definitely recommend a\n> power-of-two block size, though.\n\nSo this kind of depends on the filesystem's block size. If yours uses\nbigger blocks it's definitely recommended to adjust as needed. The block\nsize is ultimately a tradeoff, and the best value heavily depends on\nboth your system and on your use case.\n\nI'm curious though -- are you sure that this is actually the bottleneck?\nReftables are only used if you explicitly opted into them, and I would\nbe very surprised if a clone is really slowed down significantly by a\nclone.\n\nPatrick\n"}]}