linux-xfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Gionatan Danti <g.danti@assyoma.it>
To: linux-xfs@vger.kernel.org
Subject: Re: Shutdown filesystem when a thin pool become full
Date: Thu, 15 Jun 2017 13:51:13 +0200	[thread overview]
Message-ID: <a89aa00c4f86fbdc674dd8f5b5eeb248@assyoma.it> (raw)
In-Reply-To: <7e8e16f1-5425-44b3-e908-c0e8a3300e3f@assyoma.it>

Il 13-06-2017 11:09 Gionatan Danti ha scritto:
> Sorry for the bump, but further tests show unexpected behavior and I
> would really like to understand what I am missing.
> 
> Current setup:	CentOS 7.3 x86-64
> Kernel version:	3.10.0-514.21.1.el7.x86_64
> 
> LVM2 version (from lvm version):
>   LVM version:     2.02.166(2)-RHEL7 (2016-11-16)
>   Library version: 1.02.135-RHEL7 (2016-11-16)
>   Driver version:  4.34.0
> 
> On 23/05/2017 22:05, Gionatan Danti wrote:
>> 
>> Ok, I tried with a more typical non-sync write and it seems to report 
>> ENOSPC:
>> 
>> [root@blackhole ~]# dd if=/dev/zero of=/mnt/storage/disk.img bs=1M 
>> count=2048
>> dd: error writing ‘/mnt/storage/disk.img’: No space left on device
>> 2002+0 records in
>> 2001+0 records out
>> 2098917376 bytes (2.1 GB) copied, 7.88216 s, 266 MB/s
>> 
> 
> Contrary to what reported above, thin pool seems to *not* reporting
> ENOSPC when full. This means that any new data submitted to the
> filesystem will be reported as "written" but they never were.
> 
> I fully understand that application who cares for their data should
> regularly use fsync(). However, *many* application don't do that. One
> notable example is Windows Explorer: when accessing a full thinvol via
> a samba share, it will blatantly continue do "write" to the share
> without notice the user in any way that something is wrong. This is a
> recipe for disaster, as the user continues to uploads file which
> basically get lost...
> 
> Yes, the lacking fsync() use really is an application-level problem.
> However, sending files to (basically) /dev/null when the pool is full
> does not seems a smart thing.
> 
> I am surely doing wrong something, but I can not found what. Give a
> look below for how to reproduce...
> 
> # thinpool has errorwhenfull=y set
> # thinpool is 256M, thin volume is 1G
> [root@blackhole mnt]# lvs -o +whenfull
>   LV       VG        Attr       LSize   Pool     Origin Data%  Meta%
> Move Log Cpy%Sync Convert WhenFull
>   fatvol   vg_kvm    -wi-ao---- 256.00m
> 
>   storage  vg_kvm    -wi-a----- 300.00g
> 
>   thinpool vg_kvm    twi-aot--- 256.00m                 1.46   0.98
>                      error
>   thinvol  vg_kvm    Vwi-aot---   1.00g thinpool        0.37
> 
>   root     vg_system -wi-ao----  50.00g
> 
>   swap     vg_system -wi-ao----   7.62g
> 
> # current device mappings
> [root@blackhole mnt]# ls -al /dev/mapper/ | grep thin
> lrwxrwxrwx.  1 root root       7 13 giu 09.37 vg_kvm-thinpool -> 
> ../dm-7
> lrwxrwxrwx.  1 root root       7 13 giu 09.39 vg_kvm-thinpool_tdata -> 
> ../dm-5
> lrwxrwxrwx.  1 root root       7 13 giu 09.39 vg_kvm-thinpool_tmeta -> 
> ../dm-4
> lrwxrwxrwx.  1 root root       7 13 giu 09.39 vg_kvm-thinpool-tpool -> 
> ../dm-6
> lrwxrwxrwx.  1 root root       7 13 giu 10.46 vg_kvm-thinvol -> ../dm-8
> 
> # disabled ENOSPC max_retries (default value does not change anything)
> [root@blackhole mnt]# cat 
> /sys/fs/xfs/dm-8/error/metadata/ENOSPC/max_retries
> 0
> 
> # current filesystem use
> [root@blackhole mnt]# df -h | grep thin
> /dev/mapper/vg_kvm-thinvol 1021M   33M  989M   4% /mnt/thinvol
> 
> # write 400M - it should fill the thinpool
> [root@blackhole mnt]# dd if=/dev/zero of=/mnt/thinvol/disk.img bs=1M 
> count=400
> 400+0 records in
> 400+0 records out
> 419430400 bytes (419 MB) copied, 0.424677 s, 988 MB/s
> 
> ... wait 30 seconds ...
> 
> # thin pool switched to out-of-space mode
> [root@blackhole mnt]# dmesg
> [ 4408.257419] XFS (dm-8): Mounting V5 Filesystem
> [ 4408.368891] XFS (dm-8): Ending clean mount
> [ 4460.147962] device-mapper: thin: 253:6: switching pool to
> out-of-data-space (error IO) mode
> [ 4460.218484] buffer_io_error: 199623 callbacks suppressed
> [ 4460.218497] Buffer I/O error on dev dm-8, logical block 86032, lost
> async page write
> [ 4460.218510] Buffer I/O error on dev dm-8, logical block 86033, lost
> async page write
> [ 4460.218516] Buffer I/O error on dev dm-8, logical block 86034, lost
> async page write
> [ 4460.218521] Buffer I/O error on dev dm-8, logical block 86035, lost
> async page write
> [ 4460.218526] Buffer I/O error on dev dm-8, logical block 86036, lost
> async page write
> [ 4460.218531] Buffer I/O error on dev dm-8, logical block 86037, lost
> async page write
> [ 4460.218536] Buffer I/O error on dev dm-8, logical block 86038, lost
> async page write
> [ 4460.218541] Buffer I/O error on dev dm-8, logical block 86039, lost
> async page write
> [ 4460.218546] Buffer I/O error on dev dm-8, logical block 86040, lost
> async page write
> [ 4460.218551] Buffer I/O error on dev dm-8, logical block 86041, lost
> async page write
> 
> # current thinpool state
> [root@blackhole mnt]# lvs -o +whenfull
>   LV       VG        Attr       LSize   Pool     Origin Data%  Meta%
> Move Log Cpy%Sync Convert WhenFull
>   fatvol   vg_kvm    -wi-a----- 256.00m
> 
>   storage  vg_kvm    -wi-a----- 300.00g
> 
>   thinpool vg_kvm    twi-aot-D- 256.00m                 100.00 4.10
>                      error
>   thinvol  vg_kvm    Vwi-aot---   1.00g thinpool        25.00
> 
>   root     vg_system -wi-ao----  50.00g
> 
>   swap     vg_system -wi-ao----   7.62g
> 
> # write another 400M - they should *not* be allowed to complete without 
> errors
> [root@blackhole mnt]# dd if=/dev/zero of=/mnt/thinvol/disk2.img bs=1M 
> count=400
> 400+0 records in
> 400+0 records out
> 419430400 bytes (419 MB) copied, 0.36643 s, 1.1 GB/s
> 
> # no errors reported! give a look at dmesg
> 
> [root@blackhole mnt]# dmesg
> [ 4603.649156] buffer_io_error: 44890 callbacks suppressed
> [ 4603.649163] Buffer I/O error on dev dm-8, logical block 163776,
> lost async page write
> [ 4603.649172] Buffer I/O error on dev dm-8, logical block 163777,
> lost async page write
> [ 4603.649175] Buffer I/O error on dev dm-8, logical block 163778,
> lost async page write
> [ 4603.649178] Buffer I/O error on dev dm-8, logical block 163779,
> lost async page write
> [ 4603.649181] Buffer I/O error on dev dm-8, logical block 163780,
> lost async page write
> [ 4603.649184] Buffer I/O error on dev dm-8, logical block 163781,
> lost async page write
> [ 4603.649187] Buffer I/O error on dev dm-8, logical block 163782,
> lost async page write
> [ 4603.649189] Buffer I/O error on dev dm-8, logical block 163783,
> lost async page write
> [ 4603.649192] Buffer I/O error on dev dm-8, logical block 163784,
> lost async page write
> [ 4603.649194] Buffer I/O error on dev dm-8, logical block 163785,
> lost async page write
> 
> # current filesystem use
> [root@blackhole mnt]# df -h | grep thin
> /dev/mapper/vg_kvm-thinvol 1021M  833M  189M  82% /mnt/thinvol

Hi all,
any suggestion regarding the issue?

Regards.

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

  reply	other threads:[~2017-06-15 11:51 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-05-22 14:25 Shutdown filesystem when a thin pool become full Gionatan Danti
2017-05-22 23:09 ` Carlos Maiolino
2017-05-23 10:56   ` Gionatan Danti
2017-05-23 11:01     ` Gionatan Danti
2017-05-23 12:27       ` Carlos Maiolino
2017-05-23 20:05         ` Gionatan Danti
2017-05-23 21:33           ` Eric Sandeen
2017-05-24 17:52             ` Gionatan Danti
2017-06-13  9:09           ` Gionatan Danti
2017-06-15 11:51             ` Gionatan Danti [this message]
2017-06-15 13:14               ` Carlos Maiolino
2017-06-15 14:10                 ` Carlos Maiolino
2017-06-15 15:04                   ` Gionatan Danti
2017-06-20 10:19                     ` Gionatan Danti
2017-06-20 11:05                     ` Carlos Maiolino
2017-06-20 15:03                       ` Gionatan Danti
2017-06-20 15:28                         ` Brian Foster
2017-06-20 15:34                           ` Luis R. Rodriguez
2017-06-20 17:01                             ` Brian Foster
2017-06-20 15:55                           ` Gionatan Danti
2017-06-20 17:02                             ` Brian Foster
2017-06-20 18:43                               ` Gionatan Danti
2017-06-21  9:44                                 ` Carlos Maiolino
2017-06-21 10:39                                   ` Gionatan Danti
2017-06-21  9:53                                 ` Brian Foster
2017-05-23 12:11     ` Carlos Maiolino
2017-05-23 13:24 ` Eric Sandeen
2017-05-23 20:23   ` Gionatan Danti
2017-05-24  7:38     ` Carlos Maiolino
2017-05-24 17:50       ` Gionatan Danti

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=a89aa00c4f86fbdc674dd8f5b5eeb248@assyoma.it \
    --to=g.danti@assyoma.it \
    --cc=linux-xfs@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).