Linux – How to deliberately trigger a “text file busy” error

Fsck returns your filesystem to a consistent state. This is not necessarily the filesystem's “latest” state, because that state might have been lost in the crash. In fact, if there were half-written files at the time of the crash, then the filesystem was not left in a consistent state, and that is precisely what fsck is designed to repair. In other words, after running fsck, your filesystem is as up-to-date as it can get.

If your application requires feedback as to what is stored on the disk in case of a crash, you'll need to do more work than just writing to a file. You need to call sync, or better fsync, after a write operation to ensure that that particular write has been committed to the disk (but if you end up doing this a lot, your performance will drop down, and you'll want to switch to a database engine). You'll need a journaled filesystem configured for maximum crash survival (as opposed to maximum speed).

The property that an operation (such as a disk write) that has been performed cannot be undone (even in the event of a system crash) is called durability. It's one of the four fundamental properties of databases (ACID). If you need that property, read up on transactions.

Although filesystems are a kind of database, they're usually not designed to do well with respect to ACID properties: they have more emphasis on flexibility. You'll get better durability from a dedicated database engine. Then consider what happens in case your disk, and not your system crashes: for high durability, you also need replication.

If you want to ensure fragmentation but not prevent it (so you only have partial control over what happens), and you don't care about the specifics of the fragmentation, here's a quick & dirty way of doing things.

To create a file of n blocks in at least two fragments:

1. Open the file with synchronous writes, write m < n blocks.
2. Open another file. Add to it until there are at most n - m blocks free on disk. Don't make it sparse by mistake!
3. Write the remaining n - m blocks to the first file.
4. Close and unlink the second file.

You can fragment in more pieces by interlacing more files.

This assumes the filesystem is available for this sort of torture, i.e. not in a multi-user or mission-critical environment. It also assumes the filesystem has no reserved blocks, or the reserved blocks are reserved for your UID, or you're root.

There's no direct way to ensure fragmentation, because Unix systems employ filesystem abstraction, so you never talk to the raw filesystem.

Also, ensuring filesystem-level fragmentation tells you nothing about what happens at lower levels. LVM, software and hardware RAID, hardware-level sector remapping and other abstraction layers can play havoc with your expectations (and measurements).