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
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
