linux-ext4 - RE: ext4 file replace guarantees

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <C0F0BC787567C848B2C90989451123DA2363CBCC@ATLEXMBX4.ARRS.ARRISI.com>
Date:	Sat, 22 Jun 2013 14:01:39 +0000
From:	"Sidorov, Andrei" <Andrei.Sidorov@...isi.com>
To:	"Theodore Ts'o" <tytso@....edu>
CC:	"Joseph D. Wagner" <joe@...ephdwagner.info>,
	"linux-ext4@...r.kernel.org" <linux-ext4@...r.kernel.org>,
	Ryan Lortie <desrt@...rt.ca>
Subject: RE: ext4 file replace guarantees

> So if you want to use the +j flag, you have to mount the file system
> with the non-standard nodelalloc mount option.  And that's actually
> sufficient to be bug-for-bug compatible with ext3 in terms of the
> commit of the transaction which contains the rename operation first
> forcing the file out to disk first.

Thanks for pointing this, I didn't know that. In my appliance I don't benefit
from delalloc, so that's not a problem.

> The best choice for an application rewriting files <= a single 4k
> block is to use O_DIRECT to rewrite the contents of the file, using a
> 4k buffer which is zero padded.  This is the most performant, uses the
> fewest write cycles for a SSD, etc.

This doesn't work in power loss scenario.
First of all majority of hdd's still have 512b sectors, so it is possible that
hdd won't have a chance to write all 8 sectors.
This doesn't work even with 4k drives because they are susceptible to spliced
sector writes. Well, 512b are susceptible too, but 4k drives have wider
window.
That's why for rewrite to be completely safe data has to be written twice. And
that's where inode's data journalling is a win.
I guess this isn't an issue for SSD's provided they properly order remapping
(which is a bug otherwise).

Regards,
Andrey.--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html