[linux-lvm] thin handling of available space

[Xen]

Zdenek Kabelac schreef op 03-05-2016 17:45:

> It's not  'continued' suggestion.
> 
> It's just the example of solution where   'filesystem & block layer'
> are tied together.  Every solution has some advantages and
> disadvantages.

So what if more systems were tied together in that way? What would be 
the result?

Tying together does not have to do away with layers.

It is not either/or, it is both/and.

You can have separate layers and you can have intregration.

In practice all it would require is for the LVM, ext and XFS people to 
agree.

You could develop extensions to the existing protocols that are only 
used if both parties understand it.

Then pretty much btrfs has no raison d'être anymore. You would have an 
integrated system but people can retain their own identities as much as 
they want.

 From what you say LVM+ext4/XFS is already a partner system anyway.

It is CLEAR LVM+BTRFS or LVM+ZFS is NOT a popular system.

You can and you could but it does not synergize. OpenSUSE uses btrfs by 
default and I guess they use LVM just as well. For LVM you want a 
simpler filesystem that does its own work.

(At the same time I am not so happy with the RAID capability of LVM, nor 
do I care much at this point).

LVM raid seems for me the third solution after firmware raid, regular 
dmraid and .... and that.

I prefer to use LVM on top of raid really. But maybe that's not very 
helpful.


> So far I'm convinced layered design gives user more freedom - for the 
> price
> of bigger space usage.

Well let's stop directing people to btrfs then.

Linux people have a tendency and habit to send people from pillar to 
post.

You know what that means.

It means 50% of answers you get are redirects.

They think it's efficient to spend their time redirecting you or wasting 
your time in other ways, rather than using the same time and energy 
answering your question.

If the social Linux system was a filesystem, people would run benchmarks 
and complain that its organisation is that of a lunatic.

Where 50% of read requests get directed to another sector, of which 50% 
again get redirected, and all for no purpose really.

Write requests get 90% deflected. The average number of write requests 
before you hit your target is about ... it converges exactly to 10.

If I had been better at math I would have known that :p.

You say:

"Please don't compare software to real life".

No, let's compare the social world to technology. We have very bad 
technology if you look at it like that. Which in turn doesn't make the 
"real" technology much better.



SUM( i * p * (1-p)^(i-1) ) with i = (1, inf) = 1/p.

with p a chance of success at each hit.

The sum of that formula with i iterating from 1 to infinite is 1/p.

With a hit chance of 90% per attempt, the average number of hits to be 
successful is 1/.9 = 10/9.

I'm not very brilliant today.