Theodore Ts'o

There's no such thing as "optimizing for ssds" [1] That's simply irresponsible development practices. [1] https://thunk.org/tytso/blog/2009/02/22/should-filesystems-be-optimize…

I always thought Unix v7+ should have added some kind way to do atomic groups of syscalls, eg: begin_transaction (); lstat ("/path", ...); lstat ("/path/foo", ...); commit (); In Unix v7 mkdir was not a system call. It was a setuid program implemented using mknod + link. That was racy so the mkdir(2) system call was added. But it could have been solved more generally (and more elegantly) by adding transactions. It could also solve the whole thing with ending up with zero-length files because you didn't use the right incantation to update a file atomically on ext4 (https://thunk.org/tytso/blog/2009/03/12/delayed-allocation-and-the-zer…

The Android AOSP android-common kernel tree builds just fine on x86. The Qualcomm Android BSP 3.10 kernel didn't, and I had to do a huge amount of bashing and fixups before it finally could build on x86 (at least with a minimum configuration so I could run file system regression tests, since this was before android-xfstests[1] was a thing). [1] https://thunk.org/android-xfstests

Seems to exist since 2010: https://thunk.org/tytso/blog/2010/01/20/the-transitive-grace-period-pu… Originals version of the license: http://zooko.com/tgppl.html Seems like the goal was to keep the product under copyright for some time, giving it a opportunity to recover costs or integrated exclusively inside a product for a while, giving some advantage over competitors, but making it a public-license after the period. Also found this explanation: https://tahoe-lafs.org/~zooko/tgppl.pdf

Theodore Ts'o wrote about a similar Firefox issue back in 2009: https://thunk.org/tytso/blog/2009/03/15/dont-fear-the-fsync/

> Marcan links to an email by Ted Tso'o (https://lore.kernel.org/lkml/[email protected]...) that is interesting to read. Although it starts on a polarising note ("thin blue line") Can I say that I was immediately put off by the author conflating the "thin blue line" quote from with a political orientation? The full quote (from the article) being: "Later in that thread, another major maintainer unironically stated “We are the ‘thin blue line’”, and nobody cared, which just further confirmed to me that I don’t want to have anything to do with them." The way I read it, "thin blue line" is being used as a figure of speech. I get what they are referring to and I don't see an endorsement. It doesn't necessarily means a right-wing affiliation or sympathy. To me it seems like the author is projecting a right-wing affiliation and a political connotation where there is none (at least not officially, as far as I can see on https://thunk.org/tytso/) in order to discredit Theodore Ts'o. Which is a low point, because attacking Ts'o on a personal level means Martin is out of ammunitions to back their arguments. But then again, Hector Martin is the same person that though that brigading and shaming on social media is an acceptable approach to collaboration in the open source space: "If shaming on social media does not work, then tell me what does, because I'm out of ideas." from https://lkml.org/lkml/2025/2/6/404 To me, from outside, Hector Martin looks like a…

I have found a blog post from 2009 about this issue[1]. I think the "recent Ubuntu bug [that] has gotten slashdotted" is [2], so I think the most technical discussion about this would be [2]. I also found an interesting "scar tissue" from that bug in the current ext4 docs[0]: "If auto_da_alloc is enabled, ext4 will detect the replace-via-rename and replace-via-truncate patterns and force that any delayed allocation blocks are allocated such that at the next journal commit, in the default data=ordered mode, the data blocks of the new file are forced to disk before the rename() operation is committed. This provides roughly the same level of guarantees as ext3, and avoids the “zero-length” problem that can happen when a system crashes before the delayed allocation blocks are forced to disk." [0]https://docs.kernel.org/admin-guide/ext4.html [1] https://thunk.org/tytso/blog/2009/03/12/delayed-allocation-and-the-zer… [2] https://bugs.launchpad.net/ubuntu/+source/linux/+bug/317781