Linux Trace Kernel
 help / color / mirror / Atom feed
From: Steven Rostedt <rostedt@goodmis.org>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: LKML <linux-kernel@vger.kernel.org>,
	Linux Trace Kernel <linux-trace-kernel@vger.kernel.org>,
	Masami Hiramatsu <mhiramat@kernel.org>,
	Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
	Christian Brauner <brauner@kernel.org>,
	Ajay Kaher <ajay.kaher@broadcom.com>,
	Geert Uytterhoeven <geert@linux-m68k.org>,
	linux-fsdevel <linux-fsdevel@vger.kernel.org>
Subject: Re: [PATCH] eventfs: Give files a default of PAGE_SIZE size
Date: Fri, 26 Jan 2024 13:41:41 -0500	[thread overview]
Message-ID: <20240126134141.65139b5e@gandalf.local.home> (raw)
In-Reply-To: <CAHk-=whA8562VjU3MVBPMLsJ4u=ixecRpn=0UnJPPAxsBr680Q@mail.gmail.com>

On Fri, 26 Jan 2024 10:31:07 -0800
Linus Torvalds <torvalds@linux-foundation.org> wrote:

> On Fri, 26 Jan 2024 at 10:18, Steven Rostedt <rostedt@goodmis.org> wrote:
> >
> > By following what sysfs does, and give files a default size of PAGE_SIZE,
> > it allows the tar to work. No event file is greater than PAGE_SIZE.  
> 
> No, please. Just don't.
> 
> Nobody has asked for this, and nobody sane should use 'tar' on tracefs anyway.
> 
> It hasn't worked before, so saying "now you can use tar" is just a
> *bad* idea. There is no upside, only downsides, with tar either (a)
> not working at all on older kernels or (b) complaining about how the
> size isn't reliable on newer ones.
> 
> So please. You should *NOT* look at "this makes tar work, albeit badly".
> 
> You should look at whether it improves REAL LOADS. And it doesn't. All
> it does is add a hack for a bad idea. Leave it alone.
>

Fine, but I still plan on sending you the update to give all files unique
inode numbers. If it screws up tar, it could possibly screw up something
else. And all the files use to have unique numbers. They are just not unique
in the current -rc release. You have a point that this would just fix this
release and the older kernels would still be broken, but the identical inode
numbers is something I don't want to later find out breaks something.

-- Steve

  reply	other threads:[~2024-01-26 18:41 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-01-26 18:18 [PATCH] eventfs: Give files a default of PAGE_SIZE size Steven Rostedt
2024-01-26 18:31 ` Linus Torvalds
2024-01-26 18:41   ` Steven Rostedt [this message]
2024-01-26 19:06     ` Linus Torvalds
2024-01-26 19:37       ` Steven Rostedt

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=20240126134141.65139b5e@gandalf.local.home \
    --to=rostedt@goodmis.org \
    --cc=ajay.kaher@broadcom.com \
    --cc=brauner@kernel.org \
    --cc=geert@linux-m68k.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-trace-kernel@vger.kernel.org \
    --cc=mathieu.desnoyers@efficios.com \
    --cc=mhiramat@kernel.org \
    --cc=torvalds@linux-foundation.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: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox