Currently, operations on a filesystem are un-interruptible - except for network filesystems.

See TASK_KILLABLE [LWN.net, 2008].

For traditional block-based filesystems, you might predict your guarantee will be met. I don't believe TASK_KILLABLE has been adopted widely outside of network filesystems. However I would not want to assume this will always be the case, without a good reason.

If there is a possibility the application could be run on a network filesystem, it is hard to say there are strong guarantees. (And in general, e.g note NFS3 does not follow all the expectations for a POSIX filesystem).

Storage technology is also evolving. E.g. if you make an assumption based on the structure of the Linux block layer, you might be surprised when you use some future filesystem based on byte-addressable memory.

Currently, operations on a filesystem are un-interruptible - except for network filesystems.

See TASK_KILLABLE [LWN.net, 2008].

For traditional block-based filesystems, you might predict your guarantee will be met. I don't believe TASK_KILLABLE has been adopted widely outside of network filesystems. However I would not want to assume this will always be the case, without a good reason.

If there is a possibility the application could be run on a network filesystem, it is hard to say there are strong guarantees. (And in general, e.g note NFS3 does not follow all the expectations for a POSIX filesystem).

Storage technology is still evolving. E.g. if you assumed that filesystems will work a certain way based on looking at the architecture of the Linux block layer, you might be surprised in future when your application is run on a filesystem based on byte-addressable memory.

Currently, operations on a filesystem are un-interruptible - except for network filesystems.

For traditional block-based filesystems, you might predict your guarantee will be met. I don't believe TASK_KILLABLE has been adopted widely outside of network filesystems. However, I would not want to assume this will always be the case, without a good reason.

See TASK_KILLABLE [LWN.net, 2008].

If there is a possibility the application could be run on a network filesystem, it is hard to say there are strong guarantees. (And in general, e.g note NFS3 does not follow all the expectations for a POSIX filesystem).

Currently, operations on a filesystem are un-interruptible - except for network filesystems.

See TASK_KILLABLE [LWN.net, 2008].

For traditional block-based filesystems, you might predict your guarantee will be met. I don't believe TASK_KILLABLE has been adopted widely outside of network filesystems. However I would not want to assume this will always be the case, without a good reason.

If there is a possibility the application could be run on a network filesystem, it is hard to say there are strong guarantees. (And in general, e.g note NFS3 does not follow all the expectations for a POSIX filesystem).

Storage technology is also evolving. E.g. if you make an assumption based on the structure of the Linux block layer, you might be surprised when you use some future filesystem based on byte-addressable memory.