Re: [linux-lvm] Snapshot behavior on classic LVM vs ThinLVM

[Joe Thornber]

On Fri, May 12, 2017 at 03:02:58PM +0200, Gionatan Danti wrote:
> On 02/05/2017 13:00, Gionatan Danti wrote:
> >>Anyway, I think (and maybe I am wrong...) that the better solution is to
> >>fail *all* writes to a full pool, even the ones directed to allocated
> >>space. This will effectively "freeze" the pool and avoid any
> >>long-standing inconsistencies.

I think dm-thin behaviour is fine given the semantics of write
and flush IOs.

A block device can complete a write even if it hasn't hit the physical
media, a flush request needs to come in at a later time which means
'flush all IOs that you've previously completed'.  So any software using
a block device (fs, database etc), tends to generate batches of writes,
followed by a flush to commit the changes.  For example if there was a
power failure between the batch of write io completing and the flush
completing you do not know how much of the writes will be visible when
the machine comes back.

When a pool is full it will allow writes to provisioned areas of a thin to
succeed.  But if any writes failed due to inability to provision then a
REQ_FLUSH io to that thin device will *not* succeed.

- Joe

___
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] Snapshot behavior on classic LVM vs ThinLVM

[Gionatan Danti]

On 02/05/2017 13:00, Gionatan Danti wrote:



On 26/04/2017 18:37, Gionatan Danti wrote:

True, but the case exists that, even on a full pool, an application with
multiple outstanding writes will have some of them completed/commited
while other get I/O error, as writes to already allocated space are
permitted while writes to non-allocated space are failed. If, for
example, I overwrite some already-allocated files, writes will be
committed even if the pool is completely full.

In past discussion, I had the impression that the only filesystem you
feel safe with thinpool is ext4 + remount-ro, on the assumption that
*any* failed writes will trigger the read-only mode. But from my test it
seems that only *failed metadata updates* trigger the read-only mode. If
this is really the case, remount-ro really is a mandatory option.
However, as metadata can reside on alredy-allocated blocks, even of a
full pool they have a chance to be committed, without triggering the
remount-ro.

At the same time, I thought that you consider the thinpool + xfs combo
somewhat "risky", as xfs does not have a remount-ro option. Actually,
xfs seems to *always* shutdown the filesystem in case of failed metadata
update.

Maybe I misunderstood some yours message; in this case, sorry for that.

Anyway, I think (and maybe I am wrong...) that the better solution is to
fail *all* writes to a full pool, even the ones directed to allocated
space. This will effectively "freeze" the pool and avoid any
long-standing inconsistencies.

Thanks.



Hi Zdeneck, I would *really* to hear back you on these questions.
Can we consider thinlvm + xfs as safe as thinlvm + ext4 ?

Thanks.



Hi all and sorry for the bump...
Anyone with some comments on these questions?

Thanks.

--
Danti Gionatan
Supporto Tecnico
Assyoma S.r.l. - www.assyoma.it
email: g.da...@assyoma.it - i...@assyoma.it
GPG public key ID: FF5F32A8

___
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] Sector size is assumed 512

[Zdenek Kabelac]

Dne 11.5.2017 v 12:39 Tomasz Lasko napsal(a):

Hi,

I'm not a part of the list or the project, just a random guy dropping by to 
say I found one suspicious thing:


after looking for what 's' size stands for, I found that your lvmcmdline.c 
source code 
 probably 
assumes that sector size is 512, but there are various sector sizes out in 
world (both for the hardware sector size and logical disk interfaces like 
SCSI) especially more and more popular 4096 byte sector size.


I wonder if apart of lvmcmdline.c above, also other parts of your software 
assume that sector size will always be 512. If yes, then I suggest rethinking 
if 4k sectors might break some operations in LVM.


By the way, I understand that when specifying command line parameter sector 
size, then it is the same for small 's' as capital 'S', right?  And the same 
goes for bytes ('b' is the same as 'B'), right?




Hi

Sector size is 'fixed'  for  dm devices for 512b.

If you work with 4K sector disks you need to use/specify size multiplied by 8.

It would get really messy if you would have multiple different PVs in a VG 
with  different sector size and you would want to print i.e. size of LV in 
sectors.


So nope - we can't change this fixed 'base' value.

Normally users do work size in  MiB or GiB eventually TiB.

lvm2 never advises users to go to sector level precision for numerous reason.

If you care about single sector - lvm2 is likely not a tool to be considered 
for usage.



Also note - default alignment is 4MiB - so unless you would override this 
extent-size below 4K, you can't actually hit issues with wrong alignment

(and likely >99% users never change this setting)

And BTW it's explicitly mentioned that 'sector is 512b' it has not attachment 
to physical device sector size...


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/

[linux-lvm] Sector size is assumed 512

[Tomasz Lasko]

Hi,

I'm not a part of the list or the project, just a random guy dropping by 
to say I found one suspicious thing:


after looking for what 's' size stands for, I found that your 
lvmcmdline.c source code 
 
probably assumes that sector size is 512, but there are various sector 
sizes out in world (both for the hardware sector size and logical disk 
interfaces like SCSI) especially more and more popular 4096 byte sector 
size.


I wonder if apart of lvmcmdline.c above, also other parts of your 
software assume that sector size will always be 512. If yes, then I 
suggest rethinking if 4k sectors might break some operations in LVM.


By the way, I understand that when specifying command line parameter 
sector size, then it is the same for small 's' as capital 'S', right?  
And the same goes for bytes ('b' is the same as 'B'), right?


Best regards,
Tomasz Lasko


___
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/