On 12 February 2010 01:26, <tytso@xxxxxxx> 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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
