lkml.org 
[lkml]   [2014]   [May]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [RFC] Tux3 for review
Date
Hi Dongsu,

On Thursday, May 22, 2014 2:52:27 AM PDT, Dongsu Park wrote:
> First of all, thank you for trying to merge it to mainline.
> Maybe I cannot say the code is clean enough, but basically
> the filesystem seems to work at least.

Thank you for confirming that. We test Tux3 extensively so we know it works
pretty well (short of enospc handling) but independent confirmation carries
more weight than anything we could say. Our standard disclaimer: Tux3 is
for developers right now, not for users.

>> ...The files named "*_hack" were kept as close as
>> possible to the original core code to clarify exactly where core
>> needs to change in order to remove our workarounds. If you think we
>> should pretty up that code then we will happily do it. Or maybe we
>> can hammer out acceptable core patches right now, and include those
> ...
>
> Looking up kallsyms is not only hacky, but also making the filesystem
> unable to be mounted at all, when CONFIG_KALLSYMS_ALL is not defined.
> I'll send out patches to fix that separately to tux3 mailing list.

Thank you for improving the hack. We are working on getting rid of that
flusher hack completely. There is a patch under development to introduce a
new super_operationss.writeback() operation that allows a filesystem to
flush its own inodes instead of letting core do it. This will allow Tux3 to
enforce its strong ordering semantics efficiently without needing to
reimplement part of fs-writeback.c.

Regards,

Daniel


\
 
 \ /
  Last update: 2014-05-23 11:01    [W:0.125 / U:0.124 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site