On filesystem usage patterns

The ext4 data loss bug leaved some changed files with zero size in the case of a crash, making the API not transactional. The bug was fixed, not in the side of the application, but in the ext4 code itself with fixes to other delayed allocation filesystems like XFS and BTRFS to maintain semantics compatibility. I started to think about use cases both in servers and laptops to investigate if the current POSIX API of Linux and if the internal Linux filesystems implementations cover these use cases as best as possible.

• Copying, moving, creating or replacing a huge file while saving a minor setting or browsing the Internet should not ever block your GUI application noticeably.
• Modifying a file should always leave either the old one or the new one. (but never a zero length file!)
• Small file change (substitution) atomic. Transaction complete should be notified but can be delayed for some amount of time like when in laptop mode.
  
• Writes on the hard drive should always transition stable states to prevent any loss of prior data. As much only recent changes should be lost but old data should always be preserved.
• Streaming
• RDBMS tables
• Laptop-mode: the system should be able to delay writes to disk to save power by only spining the hard drive each few seconds.