From owner-freebsd-current@FreeBSD.ORG Fri Mar 30 19:42:50 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AC49E106566B; Fri, 30 Mar 2012 19:42:50 +0000 (UTC) (envelope-from utisoft@gmail.com) Received: from mail-bk0-f54.google.com (mail-bk0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 06B0B8FC08; Fri, 30 Mar 2012 19:42:49 +0000 (UTC) Received: by bkcjc3 with SMTP id jc3so1129186bkc.13 for ; Fri, 30 Mar 2012 12:42:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=8WYwW5bzafcro2BeixLU8rGCL5EjXHD6O1shRkE9G/0=; b=pOPMNuuKHFQN/dGFbfoAAswu34g5jAUCdMYw/4VxmG3IhWx7UO30Oq/UbZbXsKFD37 vFS+h3SgIw+WQ057+Drkfk+PpI3bZiJsuB1gQImOwllDOYHxvg0I1xYw85DhUA0jqF8p 8bFsmydwnxtKdfBEcvE2JMWtXIKiE5AYw03KksNURby3K+0wRhU3/3UL8IDDTegQiWMV WWdhzUKd+4VXvZqhF7YicH06qqfnzXfGT5g9uuVcnW7ijNw4eviTOVcl6Jkk/Cx7+qpP DwaU5+wGnKF0JCnViIVopSRu2w2ZXmGb6ogAfYWTnA6nsxbvdgidX+avWzqhiYBI9+4H u+eA== Received: by 10.204.10.91 with SMTP id o27mr1550243bko.5.1333136568397; Fri, 30 Mar 2012 12:42:48 -0700 (PDT) MIME-Version: 1.0 Sender: utisoft@gmail.com Received: by 10.204.202.142 with HTTP; Fri, 30 Mar 2012 12:42:18 -0700 (PDT) In-Reply-To: References: <4F746F1E.6090702@mail.zedat.fu-berlin.de> <4F74BCE8.2030802@vangyzen.net> <20120330.151848.41706133.sthaug@nethelp.no> From: Chris Rees Date: Fri, 30 Mar 2012 19:42:18 +0000 X-Google-Sender-Auth: tX7IgyRG3AUgCRmc8eJU1qnk7IU Message-ID: To: Adrian Chadd Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org, "C. P. Ghost" , sthaug@nethelp.no Subject: Re: Using TMPFS for /tmp and /var/run? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Mar 2012 19:42:50 -0000 On 30 March 2012 19:36, Adrian Chadd wrote: > On 30 March 2012 10:56, Chris Rees wrote: >> On 30 March 2012 17:31, C. P. Ghost wrote: >>> On Fri, Mar 30, 2012 at 3:18 PM, =A0 wrote: >>>>> > However, if you always want to use tmpfs instead of stable storage, >>>>> please do not. =A0Some people expect /tmp to be persistent. =A0This i= s why >>>>> /etc/defaults/rc.conf has clear_tmp_enable=3D"NO". =A0Changing this w= ould break >>>>> the POLA. >>>>> > >>>>> This is a mistake. >>>>> >>>>> The default should be clear_tmp_enable=3D"YES" >>>>> if only to uncover those broken configurations that expect /tmp to be >>>>> persistent. >>>> >>>> If you want to break POLA and make a lot of people angry, sure. >>>> Otherwise no. >>> >>> I couldn't agree more. Not clearing /tmp on reboot has been >>> the norm for way too long and it is too late to change now. >>> It's not just POLA, it also involves deleting data of unaware >>> users, and that should be avoided. >>> >>> Anyone willing to change policy w.r.t. /tmp can do so on their >>> own machines. Nothing is preventing them from doing so. >>> But by changing defaults, one should err on the side of >>> caution and remain conservative, IMHO. >> >> >From man hier: >> >> /tmp/ =A0 =A0 =A0temporary files that are not guaranteed to persist acro= ss >> system reboots >> >> This assumption that people often make 'People will be astonished by >> this'-- I would like to have someone speak up and actually say "Yes, I >> use *temporary* directories for long-term storage" rather than the >> assumption that they are around. >> >> Software that assumes this should be fixed, and it won't be until the >> bug is exposed (I'll look at eaccelerator-- it probably should store >> its cache in /var/db). >> >> Maintaining the status quo because of some hypothetical scenario isn't >> really productive. >> > Let me tell you a story. > > Someone decided that ext4 could have a decent speed up if it > implemented the posix standard for not flushing files on close(). > After all, if you needed it to be guaranteed to be written to disk, > you would call a flush routine first, before you called close(). > > So they did this. > > Then people testing out ext4 discovered that upon crash, their > kde/gnome profiles were corrupted. > > Why? Because KDE/Gnome authors hadn't ever called flush before > close(), and they weren't the only ones. They didn't read the > standard, they only used the system and fixed bugs whenever their > system behaved against their expectations. They didn't notice that the > system was being different from the standard. > > Guess what ext4 did? :) > > Don't mis-estimate POLA. Well, having thought about what this conversation was *really* about, I may have unintentionally derailed it a little. My original intention was to say to Oliver, please, don't be discouraged from using tmpfs for /tmp, and make sure you send PRs to the upstream of any programs that misbehave as such. Let's not make judgement on people who treat /tmp as persistent quite yet ;= ) Chris