Re: fsync() errors is unsafe and risks data loss

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi,

On 2018-04-11 19:32:21 -0700, Andres Freund wrote:
> And there's cases where that just doesn't help at all. Being able to
> untar a database from backup / archive / timetravel / whatnot, and then
> fsyncing the directory tree to make sure it's actually safe, is really
> not an insane idea.  Or even just cp -r ing it, and then starting up a
> copy of the database.  What you're saying is that none of that is doable
> in a safe way, unless you use special-case DIO using tooling for the
> whole operation (or at least tools that fsync carefully without ever
> closing a fd, which certainly isn't the case for cp et al).

And before somebody argues that that's a too small window to trigger the
problem realistically: Restoring large databases happens pretty commonly
(for new replicas, testcases, or actual fatal issues), takes time, and
it's where a lot of storage is actually written to for the first time in
a while, so it's far from unlikely to trigger bad block errors or such.

Greetings,

Andres Freund



[Index of Archives]     [Reiser Filesystem Development]     [Ceph FS]     [Kernel Newbies]     [Security]     [Netfilter]     [Bugtraq]     [Linux FS]     [Yosemite National Park]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Device Mapper]     [Linux Media]

  Powered by Linux