Messages in this thread | | | From | Daniel Phillips <> | Subject | Re: [RFC] Tux3 for review | Date | Fri, 23 May 2014 01:21:41 -0700 |
| |
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
| |