Am Tue, 30 Aug 2016 17:59:02 -0400 schrieb Rich Freeman <ri...@gentoo.org>:
> On Tue, Aug 30, 2016 at 4:58 PM, Volker Armin Hemmann > <volkerar...@googlemail.com> wrote: > > > > the journal does not add any data integrity benefits at all. It just > > makes it more likely that the fs is in a sane state if there is a > > crash. Likely. Not a guarantee. Your data? No one cares. > > > > That depends on the mode of operation. In journal=data I believe > everything gets written twice, which should make it fairly immune to > most forms of corruption. No, journal != data integrity. Journal only ensure that data is written transactionally. You won't end up with messed up meta data, and from API perspective and with journal=data, a partial written block of data will be rewritten after recovering from a crash - up to the last fsync. If it happens that this last fsync was half way into a file: Well, then there's only your work written upto the half of the file. A well designed application can then handle this (e.g. transactional databases). But your carefully written thesis may still be broken. Journals only ensure consistency on API level, not integrity. If you need integrity, so then file system can tell you if your file is broken or not, you need checksums. If you need a way to recover from a half written file, you need a CoW file system where you could, by luck, go back some generations. > f2fs would also have this benefit. Data is not overwritten in-place > in a log-based filesystem; they're essentially journaled by their > design (actually, they're basically what you get if you ditch the > regular part of the filesystem and keep nothing but the journal). This is log-structed, not journalled. You pointed that out, yes, but you weakened that by writing "basically the same". I think the difference is important. Mostly because the journal is a fixed area on the disk, while a log-structured file system has no such journal. > > If you want an fs that cares about your data: zfs. > > > > I won't argue that the COW filesystems have better data security > features. It will be nice when they're stable in the main kernel. This point was raised because it supports checksums, not because it supports CoW. Log structered file systems are, btw, interesting for write-mostly workloads on spinning disks because head movements are minimized. They are not automatically helping dumb/simple flash translation layers. This incorporates a little more logic by exploiting the internal structure of flash (writing only sequentially in page sized blocks, garbage collection and reuse only on erase block level). F2fs and bcache (as a caching layer) do this. Not sure about the others. Fully (and only fully) journalled file systems are a little similar for write-mostly workloads because head movements stay within the journal area but performance goes down as soon as the journal needs to be spooled to permanent storage. I think xfs spreads the journal across the storage space along with the allocation groups (thus better exploiting performance on jbod RAIDs and RAID systems that do not stripe diagonally already). It may thus also be an option for thumb drives. But it is known to prefer killing your complete file contents of what you just saved for security reasons during unclean shutdowns / unmounts. But it is pretty rock solid. And it will gain CoW support in the future which probably eliminates the kill-the-contents issue, even supporting native snapshotting then. -- Regards, Kai Replies to list-only preferred.
