I need to test git performance on a particular network setup. I don't want my test to measure hard disk write time or any other filesystem timings but network only.

Is there any trick to make git download to "null" or similar?

Note: For my desperation, the PC I have available runs Windows 10.

Thanks!

CodePudding user response：

If you have enough RAM, a ramdisk would work.

If space is an issue, possibly you could have another process deleting stuff from the ramdisk as files / directories appear, if the CPU load of scanning for them (or waiting with a notify) doesn't interfere. A fresh GIT clone might be mostly one big file so that doesn't help.

If you were using Linux instead of Windows, there are a lot of cool tricks you could use

Some of these might have Windows equivalents but I don't know what they are. Some of these might not be viable on Linux either.

On Linux, you could write a program that listens with inotify for files to be created, then uses ftruncate to discard their written blocks. Like an SSD TRIM operation, but on a file in a filesystem, punching holes in it (making it sparse) so the filesystem doesn't need to store those blocks.
You'd do this on a tmpfs filesystem, like /tmp often is; it's the go-to low-overhead Linux ramdisk-like filesystem that doesn't use a block-device at all, really just the kernel's in-memory VFS caching infrastructure.

(Windows of course makes it inconvenient to open a file while another process has it open for writing.)

Or on Linux, you could use a device-mapper virtual device with some real storage (a ramdisk) and a larger region backed by a "discard" or "zero" device that just throws away writes. (Like Simulate a faulty block device with read errors? but with a "zero" instead of "error" device, or linear with /dev/zero). Some filesystem types might be able to mkfs and mount on such a filesystem, although reading back as all zeros might crash / panic a lot of filesystems, if any metadata ever gets evicted from RAM and read back.

Or if you use a filesystem like XFS or BTRFS that can put metadata on one device, file contents on another device, you could put the metadata on a ramdisk and the file data on /dev/zero (discard writes, reads as zero). (The intended use-case is for metadata on fast RAID10 of fast disks or SSDs, data on a slower RAID5 or RAID6, especially of lower-RPM spinning rust.)

A FUSE (FS in User-Space) filesystem could probably also do this, maybe even selectively filtering files by name to have their data discarded or kept, so GIT wouldn't break if it tried to read back its data. Or keeping the first 16kiB of every file, so headers / file types can be read back. FUSE is extra filesystem overhead, though.