All of lore.kernel.org
 help / color / mirror / Atom feed
From: Martin Steigerwald <martin@lichtvoll.de>
To: Imran Geriskovan <imran.geriskovan@gmail.com>,
	linux-btrfs@vger.kernel.org
Subject: Re: Small fs
Date: Sun, 11 Sep 2016 21:21:58 +0200	[thread overview]
Message-ID: <1771908.LWBdy5fQ5X@merkaba> (raw)
In-Reply-To: <CAK5rZE6X_m6wyTmqRZ8B3TTZsXtEtPT5TaanFfgXKycJoBfsTA@mail.gmail.com>

Am Sonntag, 11. September 2016, 21:56:07 CEST schrieb Imran Geriskovan:
> On 9/11/16, Duncan <1i5t5.duncan@cox.net> wrote:
> > Martin Steigerwald posted on Sun, 11 Sep 2016 17:32:44 +0200 as excerpted:
> >>> What is the smallest recommended fs size for btrfs?
> >>> Can we say size should be in multiples of 64MB?
> >> 
> >> Do you want to know the smalled *recommended* or the smallest *possible*
> >> size?
> 
> In fact both.
> I'm reconsidering my options for /boot

Well my stance on boot still is: Ext4. Done.

:)

It just does not bother me. It practically makes no difference at all. It has 
no visible effect on my user experience and I never saw the need to snapshot /
boot.

But another approach in case you want to use BTRFS for /boot is to use a 
subvolume. Thats IMHO the SLES 12 default setup. They basically create 
subvolumes for /boot, /var, /var/lib/mysql – you name it. Big advantage: You 
have one big FS and do not need to plan space for partitions or LVs. 
Disadvantage: If it breaks, it breaks.

That said, I think at a new installation I may do this for /boot. Just put it 
inside a subvolume.

>From my experiences at work with customer systems and even some systems I 
setup myself, I often do not use little partitions anymore. I did so for a 
CentOS 7 training VM, just 2 GiB XFS for /var. Guess what happened? Last 
update was too long ago, so… yum tried to download a ton of packages and then 
complained it has not enough space in /var. Luckily I used LVM, so I enlarged 
partition LVM resides on, enlarged PV and then enlarged /var. There may be 
valid reasons to split things up, and I am quite comfortable with splitting /
boot out, cause its, well, plannable easily enough. And it may make sense to 
split /var or /var/log out. But on BTRFS I would likely use subvolumes. Only 
thing I may separate would be /home to make it easier on a re-installation of 
the OS to keep it around. That said, I never ever reinstalled the Debian on 
this ThinkPad T520 since I initially installed it. And on previous laptops I 
even copied the Debian on the older laptop onto the newer laptop. With the 
T520 I reinstalled, cause I wanted to switch to 64 bit cleanly.

-- 
Martin

  reply	other threads:[~2016-09-11 19:22 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-09-11 15:27 Small fs Imran Geriskovan
2016-09-11 15:32 ` Martin Steigerwald
2016-09-11 16:44   ` Duncan
2016-09-11 18:56     ` Imran Geriskovan
2016-09-11 19:21       ` Martin Steigerwald [this message]
2016-09-12 12:41         ` Austin S. Hemmelgarn
2016-09-12 14:09           ` Henk Slager
2016-09-12 14:12             ` Austin S. Hemmelgarn
2016-09-12 14:51             ` Chris Murphy
2016-09-12 14:56               ` Austin S. Hemmelgarn
2016-09-12  3:33       ` Duncan
2016-09-12 14:11         ` Imran Geriskovan
2016-09-12 17:43           ` Imran Geriskovan
2016-09-12 18:46             ` Imran Geriskovan
2016-09-12 18:55               ` Austin S. Hemmelgarn
2016-09-12 21:32                 ` Mike Fleetwood
2016-09-11 19:13     ` Martin Steigerwald
2016-09-11 19:46       ` Hugo Mills
2016-09-11 19:51         ` Martin Steigerwald
2016-09-12 12:45           ` Austin S. Hemmelgarn
2016-09-11 20:33 ` Chris Murphy
2016-09-12  2:00   ` Duncan
2016-09-12  3:03     ` Chris Murphy
2016-09-12  4:54       ` Duncan
2016-09-12 14:48         ` Chris Murphy
2016-09-13  4:25           ` Duncan
2016-09-12 12:54   ` Imran Geriskovan
2016-09-12 13:01     ` Austin S. Hemmelgarn

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=1771908.LWBdy5fQ5X@merkaba \
    --to=martin@lichtvoll.de \
    --cc=imran.geriskovan@gmail.com \
    --cc=linux-btrfs@vger.kernel.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 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.