[linux-lvm] thin handling of available space

[Xen]

matthew patton schreef op 27-04-2016 12:26:
> It is not the OS' responsibility to coddle stupid sysadmins. If you're
> not watching for high-water marks in FS growth vis a vis the
> underlying, you're not doing your job. If there was anything more than
> the remotest chance that the FS would grow to full size it should not
> have been thin in the first place.

Who says the only ones who would ever use or consider using thin would 
be sysadmins.?

Monitoring Linux is troublesome enough for most people and it really is 
a "job".

You seem to be intent on making the job harder rather than easy so you 
can be a type of person that has this expert knowledge while others 
don't?

I remember a reason to crack down on sysadmins was that they didn't know 
how to use "vi" - if you can't use fucking vi, you're not a sysadmin. 
This actually is a bloated version of what a system administrator is or 
could at all times be expected to do, because you are ensuring that 
problems are going to surface one way or another when this sysadmin is 
suddenly no longer capable of being this perfect guy at 100% of times.

You are basically ensuring disaster by having that attitude.

That guy that can battle against all odds and still prevail ;-).

More to the point.

No one is getting cuddled because Linux is hard enough and it is usually 
the users who are getting cuddled; strangely enough the attitude exists 
that the average desktop user never needs to look under the hood. If 
something is ugly, who cares, the "average user" doesn't go there.

The average user is oblivious to all system internals.

The system administrator knows everything and can launch a space rocket 
with nothing more than matches and some gallons of rocket fuel.

;-).


The autoextend mechanism is designed to prevent calamity when the 
filesystem(s) grow to full size. By your reasoning , it should not exist 
because it cuddles admins.

A real admin would extend manually.

A real admin would specify the right size in advance.

A real admin would use thin pools of thin pools that expand beyond your 
wildest dreams :p.

But on a more serious note, if there is no chance a file system will 
grow to full size, then it doesn't need to be that big.

But there are more use cases for thin than hosting VMs for clients.

Also I believe thin pools have a use for desktop systems as well, when 
you see that the only alternative really is btrfs and some distros are 
going with it full-time. Btrfs also has thin provisioning in a sense but 
on a different layer, which is why I don't like it.

Thin pools from my perspective are the only valid snapshotting mechanism 
if you don't use btrfs or zfs or something of the kind.

Even a simple desktop monitor, some applet with configured thin pool 
data, would of course alleviate a lot of the problems for a "casual 
desktop user". If you remotely administer your system with VNC or the 
like, that's the same. So I am saying there is no single use case for 
thin, and.

Your response mr. patton falls along the lines of "I only want this to 
be used by my kind of people".

"Don't turn it into something everyone or anyone can use".

"Please let it be something special and nichie".

You can read coddle in place of cuddle.



It seems to me pretty clear to me that a system that *requires* manual 
intervention and monitoring at all times is not a good system, 
particularly if the feedback on its current state cannot be retrieved 
from, or is usable by, other existing systems that guard against more or 
less the same type of things.

Besides, if your arguments here were valid, then 
https://bugzilla.redhat.com/show_bug.cgi?id=1189215 would never have 
existed.



> The FS already has a notion of 'reserved'. man(1) tune2fs -r

Alright thanks. But those blocks are manually reserved for a specific 
user.

That's what they are for. It is for -u. These blocks are still available 
to the filesystem.

You could call it calamity prevention as well. There will always be a 
certain amount of space for say the root user.

and by the same measure you can also say the tmpfs overflow mechanism 
for /tmp is not required either because a real admin would not see his 
rootfs go out of diskspace.

Stuff happens. You ensure you are prepared when it does. Not stick your 
head in the sand and claim that real gurus never encounter those 
situations.

The real question you should be asking is if it increases the monitoring 
aspect (enhances it) if thin pool data is seen through the lens of the 
filesystems as well.

Or whether that is going to be a detriment.

Regards.



Erratum:

https://utcc.utoronto.ca/~cks/space/blog/tech/SocialProblemsMatter

There is a widespread attitude among computer people that it is a great 
pity that their beautiful solutions to difficult technical challenges 
are being prevented from working merely by some pesky social issues 
[read: human flaws], and that the problem is solved once the technical 
work is done. This attitude misses the point, especially in system 
administration: broadly speaking, the technical challenges are the easy 
problems.

No technical system is good if people can't use it or if it makes 
people's lives harder (my words). One good example of course is Git. The 
typical attitude you get is that a real programmer has all the skills of 
a git guru. Yet git is a git. Git is an asshole system.

Beside the point here perhaps. But. Let's drop the "real sysadmin" 
ideology. We are humans. We like things to work for us. "Too easy" is 
not a valid criticism for not having something.