@marcan hm what about sync; time (tar xf linux-6.3.3.tar && sync)?
12 comments
@marcan @nicolas17 Darwin's VFS is going to have a lot of overhead anyway, I would figure due to the Mach bullshit @ariadne @marcan @nicolas17 huh? The VFS does not have anything to do with Mach whatsoever, no? This is not a microkernel system we're talking about. @bugaevc @marcan @nicolas17 every file handle in darwin is still backed by a mach port @bugaevc @marcan @nicolas17 well, for one, mmap(2) would have to somehow interact with mach ports, given that mach provides the virtual memory system. i mean, i could be wrong, i'm not terribly interested in spelunking through the Darwin source code at this immediate moment by extension, however, the point is that any resource that can possibly interact with mach should be backed by resources accessible by mach. e.g. kernel handles of all kinds. it is, admittedly possible that apple has decided to something far more cursed, like translate resources to be accessible by the mach layer as needed, but this seems far more complicated than just backing all kernel resources by mach ports to begin with though it seems that you're right that file handles do not normally have mach ports on Darwin (which is surprising to me): a program which does nothing has 11 ports opened. modify that program to open a file and it still only has 11 ports opened. 🤷 @ariadne @marcan @nicolas17 there is a semi-public way to wrap an fd into a Mach port (fileport) that you can then send to another process via Mach IPC, and then unwrap to receive an fd in the new process (kind of like SCM_RIGHTS). But this is just that, an explicit wrapper. @marcan I was thinking it could make the gap *bigger* due to macOS doing more fsync-cheating than Linux :P |
@nicolas17 Doesn't make much of a difference, the sync after only takes 0.2s or so.