On 03/14/2016 02:07 PM, Chris Murphy wrote:
On Mon, Mar 14, 2016 at 8:01 AM, Stephen Gallagher
<sgallagh(a)redhat.com> wrote:
> On 03/11/2016 06:22 PM, Chris Murphy wrote:
>> Docker isn't installed by default on Fedora Server, it only gets
>> installed if the user installs Docker.
>>
>
> I have docker installed, including docker-storage-setup.service. This file isn't
> on my filesystem. Hence why I suggested we may be looking at a changed upstream
> behavior here. Probably we can assume that this will be how it's done in F25
though.
I'm not sure what file you don't have. I haven't looked at this on
Fedora 24 yet, but on Fedora 23
$ sudo find /usr -name docker-storage-setup*
/usr/bin/docker-storage-setup
/usr/lib/systemd/system/docker-storage-setup.service
/usr/lib/docker-storage-setup
/usr/lib/docker-storage-setup/docker-storage-setup
/usr/share/man/man1/docker-storage-setup.1.gz
Ah, I was specifically looking for a file called "docker-storage-setup.conf",
but apparently that becomes /usr/lib/docker-storage-setup/docker-storage-setup
on-disk. Apologies.
> So probably best if we just set minsize 2GB and maxsize to something (I'm not
> sure about 100GiB, mostly because a lot of servers are moving to small-but-fast
> SSDs for their internal drives, but I'm open to suggestions).
Fair enough, 12GiB max? The proposal of leaving so many free extents
is "you decide" and with Cockpit it's not like this is obscured.
They're going to find out what the state of affairs is, visually, in
rather short order.
I think this is best discussed in the meeting tomorrow, but 12GiB or 15GiB seems
reasonable to me. As long as Cockpit makes it easy to extend this afterwards,
I'm good with it.
Right now, the Cockpit extend feature works, but I suspect we might want to have
the UX folks look at the experience from this use-case's perspective, since it's
likely to become more frequent and therefore should be easily discovered.
For minimum, I'd say 3GiB. My Fedora 23 Server NUC is basically
just a
Samba server with all the shared data on other volumes, root fs is
2.1GiB.
Well, a standard install of Fedora 24 as of last night's compose is 987 MiB. So
a minimum of just over double that seems acceptable to me. (All it really means
is that we will refuse to install if there isn't at least that much space on the
system, so even 1 GiB is strictly enough, unless you want to actually DO
something with the machine).
>>> That said, in a server environment there may be a decent argument for having
>>> /var on a separate partition by default, if only so that out of control logs
>>> don't fill up the system partition.
>>
>> I don't know that much of anything likes ENOSPC as a way of dealing
>> with out of control logs. If XFS project quotas weren't a pill popping
>> experience, I'd much rather use that, a warning in advance of the
>> quota being reached can be set. So another feature request for Cockpit
>> :-D
>>
>
> Would you mind filing some RFEs at
https://github.com/cockpit-project/cockpit ?
> That will be the best way to track it.
Done.
https://github.com/cockpit-project/cockpit/issues/3992
>> For Fedora 25, see if it makes sense to put root (and maybe var) on
>> virtual size LVs drawn from an LVM thin pool by default; and/or a
>> basic Cockpit interface for quotas (which means storaged needs to know
>> about quotas first probably). This might mean a slight rethink for max
>> root and var virtual size LVs, the idea being to make them as big as
>> they'd ever practically need to be, and then double that number; and
>> also consider enabling the systemd fstrim timer by default (smarter
>> than fs shrink).
>>
>
> Not going to lie: my eyes crossed reading that. I think someone is going to need
> to draw me a picture so I can follow.
There's no consequence for having an e.g. 100GiB root fs on a thin
volume that only ever uses 2GiB. The other 98GiB of extents aren't
exclusive. Therefore root fs can be made as big as it'd ever
practically need to be. And fstrim just returns any no longer used
extents back to the pool in a manner that's more effective than a
filesystem shrink would be.
OK, I follow you there. The catch of course is that all of our reporting tools
don't handle this case particularly well (since the total free space ends up
being much larger than the real space available).
Either that, or the thinp pools have to be discrete for each partition, which
rather defeats the purpose.
So for right now until the tools are updated to better express this, I'd fall on
the side of just using traditional LVM since it's easier to grok. (Yes, I
actually just said "LVM is easier to grok" than something...)