From: Daniel Phillips <daniel@phunq.net> To: David Lang <david@lang.hm> Cc: Rik van Riel <riel@redhat.com>, Jan Kara <jack@suse.cz>, <tux3@tux3.org>, Linux Kernel Mailing List <linux-kernel@vger.kernel.org>, <linux-fsdevel@vger.kernel.org>, OGAWA Hirofumi <hirofumi@mail.parknet.co.jp> Subject: Re: [FYI] tux3: Core changes Date: Fri, 31 Jul 2015 17:00:43 -0700 [thread overview] Message-ID: <b92f9d0c-21b4-4ee0-a086-c984a3785284@phunq.net> (raw) In-Reply-To: <alpine.DEB.2.02.1507311524210.11360@nftneq.ynat.uz> On Friday, July 31, 2015 3:27:12 PM PDT, David Lang wrote: > On Fri, 31 Jul 2015, Daniel Phillips wrote: > >> On Friday, July 31, 2015 11:29:51 AM PDT, David Lang wrote: ... > > you weren't asking about any particular feature of Tux, you > were asking if we were still willing to push out stuff that > breaks for users and fix it later. I think you left a key word out of my ask: "theoretical". > Especially for filesystems that can loose the data of whoever > is using it, the answer seems to be a clear no. > > there may be bugs in what's pushed out that we don't know > about. But we don't push out potential data corruption bugs that > we do know about (or think we do) > > so if you think this should be pushed out with this known > corner case that's not handled properly, you have to convince > people that it's _so_ improbable that they shouldn't care about > it. There should also be an onus on the person posing the worry to prove their case beyond a reasonable doubt, which has not been done in case we are discussing here. Note: that is a technical assessment to which a technical response is appropriate. I do think that we should put a cap on this fencing and make a real effort to get Tux3 into mainline. We should at least set a ground rule that a problem should be proved real before it becomes a reason to derail a project in the way that our project has been derailed. Otherwise, it's hard to see what interest is served. OK, lets get back to the program. I accept your assertion that we should convince people that the issue is improbable. To do that, I need a specific issue to address. So far, no such issue has been provided with specificity. Do you see why this is frustrating? Please, community. Give us specific issues to address, or give us some way out of this eternal limbo. Or better, lets go back to the old way of doing things in Linux, which is what got us where we are today. Not this. Note: Hirofumi's email is clear, logical and speaks to the question. This branch of the thread is largely pointless, though it essentially says the same thing in non-technical terms. Perhaps your next response should be to Hirofumi, and perhaps it should be technical. Regards, Daniel
WARNING: multiple messages have this Message-ID (diff)
From: Daniel Phillips <daniel@phunq.net> To: David Lang <david@lang.hm> Cc: Rik van Riel <riel@redhat.com>, Jan Kara <jack@suse.cz>, tux3@tux3.org, Linux Kernel Mailing List <linux-kernel@vger.kernel.org>, linux-fsdevel@vger.kernel.org, OGAWA Hirofumi <hirofumi@mail.parknet.co.jp> Subject: Re: [FYI] tux3: Core changes Date: Fri, 31 Jul 2015 17:00:43 -0700 [thread overview] Message-ID: <b92f9d0c-21b4-4ee0-a086-c984a3785284@phunq.net> (raw) In-Reply-To: <alpine.DEB.2.02.1507311524210.11360@nftneq.ynat.uz> On Friday, July 31, 2015 3:27:12 PM PDT, David Lang wrote: > On Fri, 31 Jul 2015, Daniel Phillips wrote: > >> On Friday, July 31, 2015 11:29:51 AM PDT, David Lang wrote: ... > > you weren't asking about any particular feature of Tux, you > were asking if we were still willing to push out stuff that > breaks for users and fix it later. I think you left a key word out of my ask: "theoretical". > Especially for filesystems that can loose the data of whoever > is using it, the answer seems to be a clear no. > > there may be bugs in what's pushed out that we don't know > about. But we don't push out potential data corruption bugs that > we do know about (or think we do) > > so if you think this should be pushed out with this known > corner case that's not handled properly, you have to convince > people that it's _so_ improbable that they shouldn't care about > it. There should also be an onus on the person posing the worry to prove their case beyond a reasonable doubt, which has not been done in case we are discussing here. Note: that is a technical assessment to which a technical response is appropriate. I do think that we should put a cap on this fencing and make a real effort to get Tux3 into mainline. We should at least set a ground rule that a problem should be proved real before it becomes a reason to derail a project in the way that our project has been derailed. Otherwise, it's hard to see what interest is served. OK, lets get back to the program. I accept your assertion that we should convince people that the issue is improbable. To do that, I need a specific issue to address. So far, no such issue has been provided with specificity. Do you see why this is frustrating? Please, community. Give us specific issues to address, or give us some way out of this eternal limbo. Or better, lets go back to the old way of doing things in Linux, which is what got us where we are today. Not this. Note: Hirofumi's email is clear, logical and speaks to the question. This branch of the thread is largely pointless, though it essentially says the same thing in non-technical terms. Perhaps your next response should be to Hirofumi, and perhaps it should be technical. Regards, Daniel
next prev parent reply other threads:[~2015-08-01 0:00 UTC|newest] Thread overview: 211+ messages / expand[flat|nested] mbox.gz Atom feed top 2015-04-28 23:13 Tux3 Report: How fast can we fsync? Daniel Phillips 2015-04-28 23:13 ` Daniel Phillips 2015-04-29 2:21 ` Mike Galbraith 2015-04-29 6:01 ` Daniel Phillips 2015-04-29 6:01 ` Daniel Phillips 2015-04-29 6:20 ` Richard Weinberger 2015-04-29 6:56 ` Daniel Phillips 2015-04-29 6:56 ` Daniel Phillips 2015-04-29 6:33 ` Mike Galbraith 2015-04-29 7:23 ` Daniel Phillips 2015-04-29 7:23 ` Daniel Phillips 2015-04-29 16:42 ` Mike Galbraith 2015-04-29 19:05 ` xfs: does mkfs.xfs require fancy switches to get decent performance? (was Tux3 Report: How fast can we fsync?) Mike Galbraith 2015-04-29 19:20 ` Austin S Hemmelgarn 2015-04-29 21:12 ` Daniel Phillips 2015-04-30 4:40 ` Mike Galbraith 2015-04-30 0:20 ` Dave Chinner 2015-04-30 3:35 ` Mike Galbraith 2015-04-30 9:00 ` Martin Steigerwald 2015-04-30 9:00 ` Martin Steigerwald 2015-04-30 14:57 ` Theodore Ts'o 2015-04-30 15:59 ` Daniel Phillips 2015-04-30 17:59 ` Martin Steigerwald 2015-04-30 11:14 ` Daniel Phillips 2015-04-30 12:07 ` Mike Galbraith 2015-04-30 12:58 ` Daniel Phillips 2015-04-30 12:58 ` Daniel Phillips 2015-04-30 13:48 ` Mike Galbraith 2015-04-30 14:07 ` Daniel Phillips 2015-04-30 14:28 ` Howard Chu 2015-04-30 14:28 ` Howard Chu 2015-04-30 15:14 ` Daniel Phillips 2015-04-30 16:00 ` Howard Chu 2015-04-30 18:22 ` Christian Stroetmann 2015-05-11 22:12 ` Pavel Machek 2015-05-11 23:17 ` Theodore Ts'o 2015-05-12 2:34 ` Daniel Phillips 2015-05-12 5:38 ` Dave Chinner 2015-05-12 6:18 ` Daniel Phillips 2015-05-12 6:18 ` Daniel Phillips 2015-05-12 18:39 ` David Lang 2015-05-12 20:54 ` Daniel Phillips 2015-05-12 21:30 ` David Lang 2015-05-12 22:27 ` Daniel Phillips 2015-05-12 22:35 ` David Lang 2015-05-12 23:55 ` Theodore Ts'o 2015-05-13 1:26 ` Daniel Phillips 2015-05-13 19:09 ` Martin Steigerwald 2015-05-13 19:37 ` Daniel Phillips 2015-05-13 20:02 ` Jeremy Allison 2015-05-13 20:02 ` Jeremy Allison 2015-05-13 20:24 ` Daniel Phillips 2015-05-13 20:25 ` Martin Steigerwald 2015-05-13 20:38 ` Daniel Phillips 2015-05-13 21:10 ` Martin Steigerwald 2015-05-13 0:31 ` Daniel Phillips 2015-05-12 21:30 ` Christian Stroetmann 2015-05-13 7:20 ` Pavel Machek 2015-05-13 13:47 ` Elifarley Callado Coelho Cruz 2015-05-12 9:03 ` Pavel Machek 2015-05-12 9:03 ` Pavel Machek 2015-05-12 11:22 ` Daniel Phillips 2015-05-12 13:26 ` Howard Chu 2015-05-11 23:53 ` Daniel Phillips 2015-05-11 23:53 ` Daniel Phillips 2015-05-12 0:12 ` David Lang 2015-05-12 4:36 ` Daniel Phillips 2015-05-12 17:30 ` Christian Stroetmann 2015-05-13 7:25 ` Pavel Machek 2015-05-13 11:31 ` Daniel Phillips 2015-05-13 12:41 ` Daniel Phillips 2015-05-13 13:08 ` Mike Galbraith 2015-05-13 13:15 ` Daniel Phillips 2015-04-30 14:33 ` Mike Galbraith 2015-04-30 15:24 ` Daniel Phillips 2015-04-30 15:24 ` Daniel Phillips 2015-04-29 20:40 ` Tux3 Report: How fast can we fsync? Daniel Phillips 2015-04-29 20:40 ` Daniel Phillips 2015-04-29 22:06 ` OGAWA Hirofumi 2015-04-29 22:06 ` OGAWA Hirofumi 2015-04-30 3:57 ` Mike Galbraith 2015-04-30 3:50 ` Mike Galbraith 2015-04-30 10:59 ` Daniel Phillips 2015-04-30 1:46 ` Dave Chinner 2015-04-30 10:28 ` Daniel Phillips 2015-04-30 10:28 ` Daniel Phillips [not found] ` <55420EAC.5040900@suse.com> 2015-04-30 11:36 ` Daniel Phillips 2015-04-30 13:19 ` Filipe David Manana 2015-04-30 13:25 ` Daniel Phillips 2015-05-01 15:38 ` Dave Chinner 2015-05-01 23:20 ` Daniel Phillips 2015-05-02 1:07 ` David Lang 2015-05-02 10:26 ` Daniel Phillips 2015-05-02 16:00 ` Christian Stroetmann 2015-05-02 16:30 ` Richard Weinberger 2015-05-02 17:00 ` Christian Stroetmann 2015-05-12 17:41 ` Daniel Phillips 2015-05-12 17:46 ` Tux3 Report: How fast can we fail? Daniel Phillips 2015-05-13 22:07 ` Daniel Phillips 2015-05-26 10:03 ` Pavel Machek 2015-05-26 10:03 ` Pavel Machek 2015-05-27 6:41 ` Mosis Tembo 2015-05-27 18:28 ` Daniel Phillips 2015-05-27 18:28 ` Daniel Phillips 2015-05-27 21:39 ` Pavel Machek 2015-05-27 22:46 ` Daniel Phillips 2015-05-28 12:55 ` Austin S Hemmelgarn 2015-05-27 7:37 ` Mosis Tembo 2015-05-27 14:04 ` Austin S Hemmelgarn 2015-05-27 15:21 ` Mosis Tembo 2015-05-27 15:37 ` Austin S Hemmelgarn 2015-05-14 7:37 ` [WIP] tux3: Optimized fsync Daniel Phillips 2015-05-14 8:26 ` [FYI] tux3: Core changes Daniel Phillips 2015-05-14 12:59 ` Rik van Riel 2015-05-15 0:06 ` Daniel Phillips 2015-05-15 0:06 ` Daniel Phillips 2015-05-15 3:06 ` Rik van Riel 2015-05-15 8:09 ` Mel Gorman 2015-05-15 9:54 ` Daniel Phillips 2015-05-15 9:54 ` Daniel Phillips 2015-05-15 11:00 ` Mel Gorman 2015-05-16 22:38 ` David Lang 2015-05-18 12:57 ` Mel Gorman 2015-05-18 12:57 ` Mel Gorman 2015-05-15 9:38 ` Daniel Phillips 2015-05-15 9:38 ` Daniel Phillips 2015-05-27 7:41 ` Pavel Machek 2015-05-27 18:09 ` Daniel Phillips 2015-05-27 18:09 ` Daniel Phillips 2015-05-27 21:37 ` Pavel Machek 2015-05-27 22:33 ` Daniel Phillips 2015-05-15 8:05 ` Mel Gorman 2015-05-17 13:26 ` Boaz Harrosh 2015-05-18 2:20 ` Rik van Riel 2015-05-18 7:58 ` Boaz Harrosh 2015-05-19 4:46 ` Daniel Phillips 2015-05-21 19:43 ` [WIP][PATCH] tux3: preliminatry nospace handling Daniel Phillips 2015-05-19 14:00 ` [FYI] tux3: Core changes Jan Kara 2015-05-19 19:18 ` Daniel Phillips 2015-05-19 20:33 ` David Lang 2015-05-19 20:33 ` David Lang 2015-05-20 14:44 ` Jan Kara 2015-05-20 16:22 ` Daniel Phillips 2015-05-20 18:01 ` David Lang 2015-05-20 18:01 ` David Lang 2015-05-20 19:53 ` Rik van Riel 2015-05-20 19:53 ` Rik van Riel 2015-05-20 22:51 ` Daniel Phillips 2015-05-20 22:51 ` Daniel Phillips 2015-05-21 3:24 ` Daniel Phillips 2015-05-21 3:51 ` David Lang 2015-05-21 19:53 ` Daniel Phillips 2015-05-21 19:53 ` Daniel Phillips 2015-05-26 4:25 ` Rik van Riel 2015-05-26 4:25 ` Rik van Riel 2015-05-26 4:30 ` Daniel Phillips 2015-05-26 4:30 ` Daniel Phillips 2015-05-26 6:04 ` David Lang 2015-05-26 6:04 ` David Lang 2015-05-26 6:11 ` Daniel Phillips 2015-05-26 6:13 ` David Lang 2015-05-26 6:13 ` David Lang 2015-05-26 8:09 ` Daniel Phillips 2015-05-26 8:09 ` Daniel Phillips 2015-05-26 10:13 ` Pavel Machek 2015-05-26 10:13 ` Pavel Machek 2015-05-26 7:09 ` Jan Kara 2015-05-26 8:08 ` Daniel Phillips 2015-05-26 8:08 ` Daniel Phillips 2015-05-26 9:00 ` Jan Kara 2015-05-26 9:00 ` Jan Kara 2015-05-26 20:22 ` Daniel Phillips 2015-05-26 21:36 ` Rik van Riel 2015-05-26 21:49 ` Daniel Phillips 2015-05-26 21:49 ` Daniel Phillips 2015-05-27 8:41 ` Jan Kara 2015-06-21 15:36 ` OGAWA Hirofumi 2015-06-21 15:36 ` OGAWA Hirofumi 2015-06-23 16:12 ` Jan Kara 2015-07-05 12:54 ` OGAWA Hirofumi 2015-07-05 12:54 ` OGAWA Hirofumi 2015-07-09 16:05 ` Jan Kara 2015-07-09 16:05 ` Jan Kara 2015-07-31 4:44 ` OGAWA Hirofumi 2015-07-31 15:37 ` Raymond Jennings 2015-07-31 17:27 ` Daniel Phillips 2015-07-31 17:27 ` Daniel Phillips 2015-07-31 18:29 ` David Lang 2015-07-31 18:29 ` David Lang 2015-07-31 18:43 ` Daniel Phillips 2015-07-31 18:43 ` Daniel Phillips 2015-07-31 22:12 ` Daniel Phillips 2015-07-31 22:12 ` Daniel Phillips 2015-07-31 22:27 ` David Lang 2015-08-01 0:00 ` Daniel Phillips [this message] 2015-08-01 0:00 ` Daniel Phillips 2015-08-01 0:16 ` Daniel Phillips 2015-08-01 0:16 ` Daniel Phillips 2015-08-03 13:07 ` Jan Kara 2015-08-01 10:55 ` Elifarley Callado Coelho Cruz 2015-08-18 16:39 ` Rik van Riel 2015-08-03 13:42 ` Jan Kara 2015-08-03 13:42 ` Jan Kara 2015-08-09 13:42 ` OGAWA Hirofumi 2015-08-10 12:45 ` Jan Kara 2015-08-10 12:45 ` Jan Kara 2015-08-16 19:42 ` OGAWA Hirofumi 2015-05-26 10:22 ` Sergey Senozhatsky 2015-05-26 12:33 ` Jan Kara 2015-05-26 12:33 ` Jan Kara 2015-05-26 19:18 ` Daniel Phillips
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=b92f9d0c-21b4-4ee0-a086-c984a3785284@phunq.net \ --to=daniel@phunq.net \ --cc=david@lang.hm \ --cc=hirofumi@mail.parknet.co.jp \ --cc=jack@suse.cz \ --cc=linux-fsdevel@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=riel@redhat.com \ --cc=tux3@tux3.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.