linux-ext4 - Re: Help on Implementation of EXT3 type Ordered Mode in EXT4

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: <38f6fb7d1002111922i4ae6131w6b5cce79344efc63@mail.gmail.com>
Date:	Fri, 12 Feb 2010 08:52:15 +0530
From:	Kailas Joshi <kailas.joshi@...il.com>
To:	tytso@....edu
Cc:	linux-ext4@...r.kernel.org, Jan Kara <jack@...e.cz>,
	Jiaying Zhang <jiayingz@...gle.com>
Subject: Re: Help on Implementation of EXT3 type Ordered Mode in EXT4

On 12 February 2010 01:26,  <tytso@....edu> wrote:
> I've mostly given up on trying to get alloc_on_commit work, for two
> reasons.
>
> The first is that one of the reasons why you might be closing the
> transaction is if there's not enough space left in the journal.  But
> if we you going to a large number of data allocations at commit time,
> there's no guaratee that there will be space in the journal for all of
> the metadata blocks that might have to be modified in order to make
> the block allocations.
Won't this get fixed by performing early reservations as mentioned in
my scheme? We are reserving required credits in the path of write
system call and these will be kept reserved until transaction commit.
So, the journal space for allocation at commit will be guaranteed.

>
> The second problem with this scheme is a performance problem; while
> you are doing handling delayed allocation blocks, you have to do this
> while the journal is still locked, using magic handles that are
> allowed to be created while the journal is locked.  That adds all
> sorts of complexity, and that seems to what you are thinking about
> doing.  The problem though is that while this is going on, all other
> file system activity has to be blocked.  So this will cause all sorts
> of processes to become suspended waiting for the all of the allocation
> activity to complete, which may require bitmap allocation blocks to be
> read into disk, etc.
Sorry, I didn't understand why processes need to be suspended.
In my scheme, I am issuing magic handle only after locking the current
transaction. AFAIK after the transaction is locked, it can receive the
block journaling requests for already created handles(in our case, for
already reserved journal space), and the new concurrent requests for
journal_start() will go to the new current transaction. Since, the
credits for locked transaction are fixed (by means of early
reservations) we can know whether journal has enough space for the new
journal_start(). So, as long as journal has enough space available,
new processes need now be stalled.

Please correct me if this is wrong.


> The trade off for all of these problems is that it allows you to delay
> the block allocation for only 5 seconds.  The question is, is this
> worth it, compared with simply mounting the file system with
> nodelalloc?  It may be all of this complexity doesn't produce enough
> of a performance gain over simply using nodelalloc.
I agree. The performance gain might not be good enough compared to
'nodelalloc'. However, our goal is providing data consistency
equivalent to Journal mode at low cost. So, we are interested in
comparing performance of alloc_on_commit (and our technique) with
performance of Journal mode.

Thanks & Regards,
Kailas
--
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