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>] [day] [month] [year] [list]
Date:	Sat, 15 May 2010 08:36:04 +0200
From:	"Amir G." <amir73il@...rs.sourceforge.net>
To:	tytso@....edu
Cc:	Ric Wheeler <rwheeler@...hat.com>, Andi Kleen <andi@...obates.de>,
	linux-ext4@...r.kernel.org
Subject: Re: Next3 - COW of data blocks

On Sat, May 8, 2010 at 9:40 PM, Amir G. <amir73il@...rs.sourceforge.net> wrote:
> On Sat, May 8, 2010 at 7:25 PM,  <tytso@....edu> wrote:
>>
>> Technically speaking, it's possible to do it both way, yes?  I'm not
>> sure why you consider this such a important design decision.  We can
>> even play games where for some files we might do copy-on-write, and
>> for some files, we do move-on-write.  It's always possible to check
>> the COW bitmaps to decide what had happened.
>>
>
> Definitely yes! I never thought it would really have to come down to a
> "decision",
> because there is a trade-off at hand.
> Even in Next3, without extents, it makes sense to have a choice of
> write performance vs. fragmentation per file.
> The few applications that use random in-place write (db, virtual disk)
> would probably want to avoid the fragmentation.
>

There is another challenge concerning COW of non-journaled data blocks.

With COW of metadata blocks, the order of I/O is guarantied to
preserve snapshot consistency after crash,
because snapshot data blocks (the copied block) are ordered and both
snapshot metadata blocks and original COWed metadata block are
journaled in the same transaction.

With move-on-write of non-journaled data blocks, the entire move block
operation is journaled, the snapshot data block is
a moved block, so has no I/O at all, and the new data block is
whatever (ordered,writeback).

If Next3 were to implement COW of non-journaled data blocks (i.e.,
ordered or writeback) to avoid the file fragmentation,
how can it assure the correct order of I/O between the COWed data
block and the snapshot copied block without using synchronic I/O?

Can someone propose a solution to that challenge?

Amir.
--
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ