Re: [linux-lvm] thin handling of available space
Hello Xen, Wednesday, April 27, 2016, 23:28:31, you wrote: > 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. > 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. As far as I know (someone correct me) there is no mechanism at all in kernel for communication from lower fs layers to higher layers - besides exporting static properties like physical block size. The other way (from higher layer like fs to lower layers works fine - for example discard support). So even if what you are asking might be valid, it isn't as simple as adding some parameter somewhere and it would magically work. It is about inventing and standardizing new communication system, which would of course work only with new versions of all the tools involved. Anyway, I have no idea what would filesystem itself do with information that no more space is available. Also this would work only for lvm thin pools, not for thin provision directly from storage, so it would be a non-consistent mess. Or you would need another protocol for exporting thin-pool related dynamic data from storage (via NAS, SAN, iSCSI and all other protocols) to the target system. And in some organizations it is not desirable at all to make this kind of information visible to all target systems / departments. What you are asking can be done for example directly in "df" (or you can make a wrapper script), which would not only check the filesystems themselves, but also the thin part and display the result in whatever format you want. Also displaying real thin free space for each fs won't be "correct". If I see 1 TB free in each filesystem and starting writing, by the time I finish, those 1 TB might be taken by the other fs. So information about current free space in thinp is useless for me, as in 1 minute it could be totally different number. -- bYE, Marki ___ 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/
Re: [linux-lvm] about the lying nature of thin
Hello Xen, Friday, April 29, 2016, 0:37:23, you wrote: > In practical matters a thin volume only starts to lie when "real space" > < "virtual space" -- a condition you are normally trying to avoid. > Thin pools do not lie by default. They lie when they cannot fulfill > their obligations, and this is precisely the reason for the idea I > suggested: to stop the lie, to be honest. I would say that thin provisioning is designed to lie about the available space. This is what it was invented for. As long as the used space (not virtual space) is not greater then real space, everything is ok. Your analogy with customers still applies and whole IT business is based on it (over-provisioning home internet connection speed, "guaranteed" webhosting disk space). It seems to me that disk space was the last thing to get over- (or thin-) provisioned :) Now I'm not sure what your use-case for thin pools is. I don't see it much useful if the presented space is smaller than available physical space. In that case I can just use plain LVM with PV/VG/LV. For snaphosts you don't care much as if the snapshot overfills, it just becomes invalid, but won't influence the original LV. But their use case is to simplify the complexity of adding storage. Traditionally you need to add new physical disks to the storage / server, add it to LVM as new PV, add this PV to VG, extend LV and finally extend filesystem. Usually the storage part and server (LVM) part is done by different people / teams. By using thinp, you create big enough VG, LV and filesystem. Then as it is needed you just add physical disks and you're done. Another benefit is disk space saving. Traditionally you need to have some reserve as free space in each filesystem for growth. With many filesystems you just wasted a lot of space. With thinp, this free space is "shared". And regarding your other mail about presenting parts / chunks of blocks from block layer... This is what device mapper (and LVM built on top of it) does - it takes many parts of many block devices and creates new linear block device out of them (whether it is stripped LV, mirrored LV, dm-crypt or just concatenation of 2 disks). -- bYE, Marki ___ 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/
Re: [linux-lvm] convert LV to physical device _in_place_?
Hello Zdenek, Thursday, July 13, 2017, 17:25:10, you wrote: > However if you have been having a single 'segment' LV and and you calculate > proper skipping offset (typically 1MB) you can try to use such device directly > without lvm2 with a loop device mapping - see losetup --offset option - but > you would need to use this everytime you want to access such storage - so > there is not a single magic 'flip' which would make an LV to appear like > regular device. Wouldn't creating a partition with correct start sector work as a permanent solution? (Although I didn't understand if using a partition is an option for the original poster.) -- bYE, Marki ___ 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/
Re: [linux-lvm] Is TRIM and DISCARD needed for normal HDD ?
Title: Re: [linux-lvm] Is TRIM and DISCARD needed for normal HDD ? Hi, TRIM is also used on some SMR HDDs. https://superuser.com/questions/1407990/what-does-trim-on-an-hdd-mean Wednesday, November 25, 2020, 16:37:07, you wrote: Hi, I am using thin LVM pools, but I have a normal hard disk and not a SSD. Is there any reason to enable TRIM and/or DISCARD for my HDD ? I have heard it is only useful for a SSD. Will it offer any advantages in my case ? -- Regards, Sreyan Chakravarty -- bYE, Marki ___ 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/
