Forked from: Building ports with USE_SYSTRACE=Yes
Curious about how 'mkdir -p' and 'install -d' are touching the filesystem, I quickly ended up in the source code which led me to a [very] brief discussion/mention of the latest revision of mkdir.
From - Fixing mkdir -p vs. systrace
Here's a goofy way to watch concurrency collisions occur on filesystem operations.
#!/bin/ksh I=0 J=$HOME while [ $I -lt 80 ] do I=`expr $I + 1` J=$J/$I mkdir -p $J done
#!/bin/ksh I=0 while [ $I -lt 80 ] do I=`expr $I + 1` rm -r $HOME/1 done
#!/bin/ksh foo.ksh & foo.ksh & bar.ksh & foo.ksh & foo.ksh &
Both rm and mkdir should fail in a various ways. If there was some kind of concurrency control on the filesystem such that each rm and mkdir operation were an atomic transaction, this wouldn't happen. But there's not, so it does. I don't think tuning mkdir would solve the fundamental issue in any significant way (a very fast mkdir might have a lower probability of concurrency collisions than a very slow mkdir).
Assuming all of this is correct, I think the systrace friendly version of mkdir is nicer (well, if there were also a systrace friendly version of install).
Is this all crazy (have I missed the boat somewhere)?
|Thread||Thread Starter||Forum||Replies||Last Post|
|filesystem full?||amandus||FreeBSD General||11||11th June 2013 12:10 PM|
|mounting hfsplus filesystem||daemonfowl||OpenBSD General||17||7th September 2012 08:24 PM|
|dvd filesystem type||chill||FreeBSD General||6||17th June 2008 08:22 AM|
|Best Filesystem||thavinci||FreeBSD General||25||29th May 2008 03:32 PM|
|Filesystem read errors||Foon||FreeBSD General||0||10th May 2008 07:27 AM|