linux-kernel - Re: [PATCH 3/3] Add timeout feature

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: <487B51DD.2080206@hp.com>
Date:	Mon, 14 Jul 2008 09:17:17 -0400
From:	jim owens <jowens@...com>
To:	Pavel Machek <pavel@...e.cz>
CC:	linux-fsdevel@...r.kernel.org, Dave Chinner <david@...morbit.com>,
	Theodore Tso <tytso@....edu>,
	Arjan van de Ven <arjan@...radead.org>,
	Miklos Szeredi <miklos@...redi.hu>, hch@...radead.org,
	t-sato@...jp.nec.com, akpm@...ux-foundation.org,
	viro@...IV.linux.org.uk, linux-ext4@...r.kernel.org,
	xfs@....sgi.com, dm-devel@...hat.com, linux-kernel@...r.kernel.org,
	axboe@...nel.dk, mtk.manpages@...glemail.com
Subject: Re: [PATCH 3/3] Add timeout feature

Pavel Machek wrote:

> If you also freeze data writes, at least snapshot is not worse than
> _unexpected_ shutdown.

True.  But the key point is also that stopping file writes is
__no better__ than an unexpected shutdown for applications.

Once kernel people accept that it is identical to an unknown
shutdown state, they realize that as you said...

> And apps should already be ready for unexpected shutdowns (using fsync
> etc).

The people writing the code outside the kernel are the ones
responsible for the logic of handling "we don't know what
application writes made it to disk".

Remember that immediately after fsync(), the next write
can make the file inconsistent.  For example, look at this
simple sales processing database type sequence:

    write(sale_last_name_file, "Mackek"
    write(sale_first_name_file, "Pavel")
    fsync(sale_last_name_file)
    fsync(sale_first_name_file)
       ...
    write(sale_last_name_file, "Owens")
    write(sale_first_name_file, "Jim")
    fsync(sale_last_name_file)

FREEZEFS [defined to NOT allow file data writes]

So if we restart from that snapshot, the sales order
thinks the customer is "Pavel Owens"... unless there
is some mechanism such as seqence numbers that tie
the files together.  And if they have such a mechanism
then it doesn't matter if we allow even more writes
such as:

    write(sale_first_name_file, "Ted")

There just is no way inside the kernel to know a
freeze was triggered at a stable application point
such that data before the freeze must be on disk
and data after the freez must not go to disk.

This issue is not unique to freeze, it is also
present with filesystems that have snapshots and
cow/versioning built in.

jim
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/