On 17.5.2016 19:17, Xen wrote:
Strange, I didn't get my own message.
Zdenek Kabelac schreef op 17-05-2016 11:43:
There is no plan ATM to support boot from thinLV in nearby future.
Just use small boot partition - it's the safest variant - it just hold
kernels and ramdisks...
That's not what I meant. Grub-probe will fail when the root filesystem is on
thin, thereby making impossible the regeneration of your grub config files in
/boot/grub.
It will try to find the device for mounted /, and not succeed.
Booting thin root is perfectly possible, ever since Kubuntu 14.10 at least (at
least januari 2015).
We aim for a system with boot from single 'linear' with individual
kernel + ramdisk.
It's simple, efficient and can be easily achieved with existing
tooling with some 'minor' improvements in dracut to easily allow
selection of system to be used with given kernel as you may prefer to
boot different thin snapshot of your root volume.
Sure but won't happen if grub-update bugs on thin root.
I'm not sure why we are talking about this now, or what I asked ;-).
The message behind is - bootting from 'linear' LVs, and no msdos partions...
So right from a PV.
Grub giving you 'menu' from bootable LVs...
BootableLV combined with selected 'rootLV'...
Complexity of booting right from thin is very high with no obvious benefit.
I understand. I had not even been trying to achieve yet, although it has or
might have principal benefit, the way doing away with partitions entirely
(either msdos or gpt) has a benefit on its own.
But as you indicate, you can place boot on non-thin LVM just fine, so there is
not really that issue as you say.
But for me, a frozen volume would be vastly superior to the system locking up.
You miss the knowledge how the operating system works.
Your binary is 'mmap'-ed for a device. When the device holding binary
freezes, your binary may freeze (unless it is mlocked in memory).
So advice here is simple - if you want to run unfreezable system -
simply do not run this from a thin-volume.
I did not run from a thin-volume, that's the point.
In my test, the thin volumes were created on another harddisk. I created a
small partition, put a thin pool in it, put 3 thin volumes in it, and then
overfilled it to test what would happen.
It's the very same issue if you'd have used 'slow' USB device - you may slow
down whole linux usage - or in similar way building 4G .iso image.
My advice - try lowering /proc/sys/vm/dirty_ration - I'm using '5'....
The best advice we have - 'monitor' fullness - when it's above - stop
using such system and ensure there will be more space - there is
noone else to do this task for you - it's the price you pay for
overprovisioning.
The point is that not only as an admin (for my local systems) but also as a
developer, there is no point in continuing a situation that could be mitigated
by designing tools for this purpose.
There is no point for me if I can make this easier by automating tools for
performing these tasks, instead of doing them by hand. If I can create tools
or processes that do, what I would otherwise have needed to do by hand, then
there is no point in continuing to do it by hand. That is the whole point of
"automation" everywhere.
Policies are hard and it's not quite easy to have some universal,
that fits everyone needs here.
On the other hand it's relatively easy to write some 'tooling' for your
particular needs - if you have nice 'walled' garden you could easily target it...
"Monitoring" and "stop using" is a process or mechanism that may very well be
encoded and be made default, at least for my own systems, but by extension, if
it works for me, maybe others can benefit as well.
Yes - this part will be extended and improved over the time.
Already few BZ exists...
It just takes time....
I am not clear why a forced lazy umount is better, but I am sure you have your
reason for it. It just seems that in many cases, an unwritable but present
(and accessible) filesystem is preferable to none at all.
Plain simplicity - umount is simple sys call, while 'mount -o remount,ro' is
relatively complicated resource consuming process. There are some technical
limitation related to usage operations like this behind 'dmeventd' - so it
needs some redesigning for these new needs....
I do not mean any form of differentiation or distinction. I mean an overall
forced read only mode on all files, or at least all "growing", for the entire
volume (or filesystem on it) which would pretty much be the equivalent of
remount,ro. The only distinction you could ever possibly want in there is to
block "new growth" writes while allowing writes to existing blocks. That is
the only meaningful distinction I can think of.
Of course, it would be pretty much equivalent to a standard mount -o
remount,ro, and would still depend on thin pool information.
To give some 'light' where is the 'core of problem'
Imaging you have few thin LVs.
and you operate on a single one - which is almost fully provisioned
and just a single chunk needs to be provisioned.
And you fail to write. It's really nontrivial to decided what needs
to happen.
Worth to note here - you can set your thin-pool with 'instant'
erroring in case you know you do not plan to resize it (avoiding
'freeze')
lvcreate/lvchange --errorwhenfull y|n
Ah thank you, that could solve it. I will try again with the thin test the
moment I feel like rebooting again. The harddrive is still available, haven't
installed my system yet.
Maybe that should be the default for any system that does not have autoextend
configured.
Yep policies, policies, policies....
Regards
Zdenek
_______________________________________________
linux-lvm mailing list
linux-lvm@redhat.com
https://www.redhat.com/mailman/listinfo/linux-lvm
read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
