[gentoo-user] Re: USB crucial file recovery

[Kai Krakow]

Am Tue, 30 Aug 2016 17:59:02 -0400
schrieb Rich Freeman <rich0@g.o>:

> On Tue, Aug 30, 2016 at 4:58 PM, Volker Armin Hemmann
> <volkerarmin@××××××××××.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.