Re: [RFC] Tux3 for review
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 ___ Tux3 mailing list Tux3@phunq.net http://phunq.net/mailman/listinfo/tux3
Re: [RFC] Tux3 for review
Hi, On 19.05.2014 17:55, Daniel Phillips wrote: On 05/18/2014 04:55 PM, Dave Chinner wrote: On Fri, May 16, 2014 at 05:50:59PM -0700, Daniel Phillips wrote: We would like to offer Tux3 for review for mainline merge. We have prepared a new repository suitable for pulling: https://git.kernel.org/cgit/linux/kernel/git/daniel/linux-tux3.git/ 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. Then there's all the writeback hacks. You've simply copy-n-pasted most of fs-writeback.c, including duplicating structures like struct wb_writeback_work and then hacked in crap (kallsyms lookups!) to be able to access core structures from kernel module context (tux3_setup_writeback(), I'm looking at you). This is intentional. 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 with our merge proposal. That would make us even happier. We hate those hacks as much as you do. 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. Regards, Dongsu ___ Tux3 mailing list Tux3@phunq.net http://phunq.net/mailman/listinfo/tux3
Re: [RFC] Tux3 for review
Hi Dave, This is to address your concern about theoretical interaction between direct IO and Tux3 page fork. On Monday, May 19, 2014 10:41:40 PM PDT, I wrote: Except that Direct IO impacts on the design of the page forking code (because of how things like get_user_pages() need to be aware of page forking). So you need to have direct IO working to demonstrate that the page forking design is sound. Page fork only affects cache pages, so the only interation with direct IO is when the direct IO is to/from a mmap. If a direct write races with a programmed write to cache that causes a fork, then get_user_pages may pick up the old or new version of a page. It is not defined which will be written to disk, which is not a surprise. If a direct read races with a programmed write to cache that causes a fork, then it might violate our strong ordering, but that is not a surprise. I do not see any theoretical oopses or life cycle issues. So Tux3 may allow racy direct read to violate strong ordering, but strong ordering would still be available with proper application sequencing. For example, direct read to mmap followed by msync would be strongly ordered. Regards, Daniel ___ Tux3 mailing list Tux3@phunq.net http://phunq.net/mailman/listinfo/tux3
Re: [RFC] Tux3 for review
Hi Daniel! Am Freitag, 16. Mai 2014, 17:50:59 schrieb Daniel Phillips: We would like to offer Tux3 for review for mainline merge. We have prepared a new repository suitable for pulling: At long last! Congrats for arriving at this point. Ciao, -- Martin 'Helios' Steigerwald - http://www.Lichtvoll.de GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7 ___ Tux3 mailing list Tux3@phunq.net http://phunq.net/mailman/listinfo/tux3
Re: [RFC] Tux3 for review
On Friday, May 16, 2014 10:09:50 PM PDT, Martin Steigerwald wrote: Hi Daniel! Am Freitag, 16. Mai 2014, 17:50:59 schrieb Daniel Phillips: We would like to offer Tux3 for review for mainline merge. We have prepared a new repository suitable for pulling: At long last! Congrats for arriving at this point. Ciao, Hi Martin, Thanks, Hirofumi is the one who deserves congratulations, recognition for providing more than half the code including most of the hard parts, and thanks for bringing Tux3 back to life. Regards, Daniel ___ Tux3 mailing list Tux3@phunq.net http://phunq.net/mailman/listinfo/tux3
