manual trigger for filesystem extension? #391

erickj · 2022-01-12T18:40:02Z

erickj
Jan 12, 2022

My system seems to have some similar sounds issues to those described in stratis-storage/stratisd#2814
Particularly it looks to me like stratis thin provisioning isn't triggering file system extension for a few of my filesystems (see paste below).

Is there a suggested way to "kick" stratis to initialize resizing? is invoking lvextend manually discouraged?

$ stratis blockdev
Pool Name            Device Node   Physical Size   Tier
io.vos               /dev/sda           3.64 TiB   Data
io.vos               /dev/sdb           3.64 TiB   Data
local.volatile       /dev/sdd         119.24 GiB   Data
net.ejjohnson.home   /dev/sdc           2.73 TiB   Data
19:34:12 [erick@jupiter:~] 
$ stratis pool
Name                                     Total Physical   Properties                                   UUID
io.vos                7.28 TiB / 1023.62 GiB / 6.28 TiB      ~Ca,~Cr   8d86f3f6-8666-490b-99b0-b5c6a5fc7986
local.volatile       119.24 GiB / 2.06 GiB / 117.19 GiB      ~Ca,~Cr   c70a5b86-fa15-45b3-a71e-4a9f78d1e340
net.ejjohnson.home     2.73 TiB / 2.00 TiB / 747.14 GiB      ~Ca,~Cr   7e18ddcd-9924-4c92-b926-100a7498630b
19:34:15 [erick@jupiter:~] 
$ stratis fs
Pool Name            Name     Used          Created             Device                                   UUID                                
io.vos               fs_raw   1023.97 GiB   Feb 16 2019 19:43   /dev/stratis/io.vos/fs_raw               e8071df3-346a-4753-bda1-524c84d037f9
local.volatile       tmp      2.01 GiB      Aug 31 2019 23:39   /dev/stratis/local.volatile/tmp          8bec6004-cfe7-4820-99c3-1a827d37ba7f
net.ejjohnson.home   fs_nas   2.00 TiB      Aug 04 2019 16:18   /dev/stratis/net.ejjohnson.home/fs_nas   779e3ab9-7b24-4bc4-9628-3ae2f21e8cad
19:34:17 [erick@jupiter:~] 
$ df -h /mnt/io.vos_raw/
Filesystem                                                                                       Size  Used Avail Use% Mounted on
/dev/mapper/stratis-1-8d86f3f68666490b99b0b5c6a5fc7986-thin-fs-e8071df3346a4753bda1524c84d037f9  1.0T 1023G  671M 100% /mnt/io.vos_raw

$ stratis daemon version
2.4.4
19:37:37 [erick@jupiter:~] 
$ stratis --version
2.4.4

Answered by erickj

Jan 17, 2022

@jbaublitz - so I just did a dnf update and stratis upgraded to 3.0.2.

The volumes seemed to have resized on their own. This issue is solved from my perspective. Thank you

23:30:48 [erick@jupiter:~] 
$ journalctl -u stratisd.service | grep version | tail
Dec 15 16:36:40 jupiter stratisd[1535]: [2021-12-15T15:36:40Z INFO  stratisd::stratis::run] stratis daemon version 2.4.4 started
Dec 15 16:51:25 jupiter stratisd[1451]: [2021-12-15T15:51:25Z INFO  stratisd::stratis::run] stratis daemon version 2.4.4 started
Dec 15 16:58:57 jupiter stratisd[1516]: [2021-12-15T15:58:57Z INFO  stratisd::stratis::run] stratis daemon version 2.4.4 started
Dec 20 19:21:45 jupiter stratisd[1577]: [2021-12-20T18:…

View full answer

jbaublitz · 2022-01-13T14:56:36Z

jbaublitz
Jan 13, 2022
Maintainer

Hi @erickj! I did a lot of digging into this and think I have an idea of what's going on.

First, do you have a process to reproduce this? We want to make sure that we can put some kind of test in place to ensure that this doesn't happen in #2814.

For some background, filesystem extension and thin pool event handling is done in the same method which will be changed in #2814. My understanding of how this worked is that the thin pool low water mark would be set to 2 GiB less than the current free space. This would trigger a devicemapper low water mark event every 2 GiB written to the pool. Filesystems are supposed to extend when there is only 8 GiB left of space so theoretically, the filesystem usage should always be checked and extended before it runs out of space.

My guess at what is happening is that 2 GiB is not a huge amount of data to write. On faster machines and drives, it doesn't seem unreasonable that more than 2 GiB could be written or even flushed from the XFS cache between the time that the pool usage is determined and the time when then new low water mark is set. The low water mark only triggers an event when it is passed, not simply when the free space is less than the low water mark so if the pool has 5 GiB left, the next low water mark is determined to be 3 GiB left and then 2.5 GiB gets written and there is only 2.5 GiB of free space left before the 3 GiB low water mark is set, the devicemapper event would never fire again until the pool starts running out of space (which it is not in your case). This seems like the most likely issue and I would love to confirm this.

If this is indeed the issue, #2814 should solve this. As for a solution in the meantime, stratisd only runs the filesystem check method on devicemapper events and start up. Restarting stratisd should cause the pools to run the checking method again. This should determine that the XFS filesystem needs to be extended from the usage and cause it to expand. It is unfortunately rather difficult to generate a devicemapper event so this seems like your best option. If you are interested in confirming that this is the problem before you fix it (which would help us a lot), here is an example output from dmsetup table from #2814:

stratis-1-private-ca5cd5169e9e4137a84b1bda39e25b4f-thinpool-pool: 0 31395840 thin-pool 253:5 253:6 2048 2048 3 skip_block_zeroing no_discard_passdown error_if_no_space

The 4th argument after thin-pool is the current low water mark for the thin pool. It represents the number of 1 MiB blocks of free space left when the low water mark signal is sent. To confirm this explanation, please provide your low water mark value for the pool that has stopped extending filesystems. Theoretically this should be higher than the amount of free space that you have left in the pool.

Hopefully this helps some and if this doesn't resolve the issue, please do let us know!

0 replies

erickj · 2022-01-13T22:39:39Z

erickj
Jan 13, 2022
Author

do you have a process to reproduce this?

unless "setup stratisd 3 years ago, and upgrade your workstation 6 times" is a viable repro, then unfortunately... no. I will say that I went through a recent rough patch of an upgrade from 34->35 resulting in an SELinux relabel to /. I have not idea if this is actually related to any recent stratis issues I've seen

dmsetup table

here is the output for all drives listed above. I'm expecting both 7e18ddcd-9924-4c92-b926-100a7498630b and 8d86f3f68666490b99b0b5c6a5fc7986 to resize

$ dmsetup table
stratis-1-private-7e18ddcd99244c92b926100a7498630b-flex-mdv: 0 32768 linear 253:9 1638400
stratis-1-private-7e18ddcd99244c92b926100a7498630b-flex-thindata: 0 1572864 linear 253:9 65536
stratis-1-private-7e18ddcd99244c92b926100a7498630b-flex-thindata: 1572864 5853052928 linear 253:9 7471104
stratis-1-private-7e18ddcd99244c92b926100a7498630b-flex-thinmeta: 0 32768 linear 253:9 0
stratis-1-private-7e18ddcd99244c92b926100a7498630b-flex-thinmeta: 32768 5799936 linear 253:9 1671168
stratis-1-private-7e18ddcd99244c92b926100a7498630b-physical-originsub: 0 5860524032 linear 8:32 8192
stratis-1-private-7e18ddcd99244c92b926100a7498630b-thinpool-pool: 0 5854625792 thin-pool 253:10 253:11 2048 760249 3 skip_block_zeroing no_discard_passdown error_if_no_space 
stratis-1-private-8d86f3f68666490b99b0b5c6a5fc7986-flex-mdv: 0 32768 linear 253:15 1638400
stratis-1-private-8d86f3f68666490b99b0b5c6a5fc7986-flex-thindata: 0 1572864 linear 253:15 65536
stratis-1-private-8d86f3f68666490b99b0b5c6a5fc7986-flex-thindata: 1572864 15610820608 linear 253:15 17235968
stratis-1-private-8d86f3f68666490b99b0b5c6a5fc7986-flex-thinmeta: 0 32768 linear 253:15 0
stratis-1-private-8d86f3f68666490b99b0b5c6a5fc7986-flex-thinmeta: 32768 15564800 linear 253:15 1671168
stratis-1-private-8d86f3f68666490b99b0b5c6a5fc7986-physical-originsub: 0 7814028976 linear 8:16 8192
stratis-1-private-8d86f3f68666490b99b0b5c6a5fc7986-physical-originsub: 7814028976 7814027600 linear 8:0 8192
stratis-1-private-8d86f3f68666490b99b0b5c6a5fc7986-thinpool-pool: 0 15612393472 thin-pool 253:16 253:17 2048 6573090 3 skip_block_zeroing no_discard_passdown error_if_no_space 
stratis-1-private-c70a5b86fa1545b3a71e4a9f78d1e340-flex-mdv: 0 32768 linear 253:3 1638400
stratis-1-private-c70a5b86fa1545b3a71e4a9f78d1e340-flex-thindata: 0 1572864 linear 253:3 65536
stratis-1-private-c70a5b86fa1545b3a71e4a9f78d1e340-flex-thindata: 1572864 248193024 linear 253:3 1867776
stratis-1-private-c70a5b86fa1545b3a71e4a9f78d1e340-flex-thinmeta: 0 32768 linear 253:3 0
stratis-1-private-c70a5b86fa1545b3a71e4a9f78d1e340-flex-thinmeta: 32768 196608 linear 253:3 1671168
stratis-1-private-c70a5b86fa1545b3a71e4a9f78d1e340-physical-originsub: 0 250060800 linear 8:48 8192
stratis-1-private-c70a5b86fa1545b3a71e4a9f78d1e340-thinpool-pool: 0 249765888 thin-pool 253:4 253:5 2048 117851 3 skip_block_zeroing no_discard_passdown error_if_no_space

6 replies

jbaublitz Jan 14, 2022
Maintainer

Hi @erickj. From what I'm seeing the low water mark is actually lower than the amount of free space currently reported on your pool. The low water mark is approximately 6.26 TiB while the amount of free space is 6.28 TiB. This means that the low water mark was set appropriately and has not been reached yet. Could you please provide the output of dmsetup status for the filesystem that is not extending? If the thin device has gone into a failed state, that would also cause the filesystem not to be extended. Furthermore, this would explain why restarting stratisd did not extend it. This should have kicked the filesystem to extend if there were simply a missing low water mark. However, if it is in a failed state, it makes sense from looking at the code that it would not.

I think the command should be sudo dmsetup status /dev/mapper/stratis-1-8d86f3f68666490b99b0b5c6a5fc7986-thin-fs-e8071df3346a4753bda1524c84d037f9 based on the output in the first post you provided.

jbaublitz Jan 14, 2022
Maintainer

Also dmsetup status for the thin pool device as well would be helpful!

erickj Jan 14, 2022
Author

Could you please provide the output of dmsetup status for the filesystem that is not extending?

$ sudo dmsetup status /dev/mapper/stratis-1-8d86f3f68666490b99b0b5c6a5fc7986-thin-fs-e8071df3346a4753bda1524c84d037f9
0 2147483648 thin 2147416064 2147483647

Also dmsetup status for the thin pool device as well would be helpful!

$ sudo dmsetup status
...
stratis-1-private-8d86f3f68666490b99b0b5c6a5fc7986-thinpool-pool: 0 15612393472 thin-pool 0 11931/1949696 1048543/7623239 - rw no_discard_passdown error_if_no_space - 1024

Thank you. Please let me know if there is more info that could continue to be useful to diagnose the issue.

jbaublitz Jan 17, 2022
Maintainer

Are you able to upload the logs dating back to right before you noticed the issue? What I'm seeing here is helpful but inconclusive.

Based on what I'm seeing, the low water mark is around 1.5 GiB less than the free space available on the pool. This seems to indicate that it was crossed and set lower which should have triggered the filesystem checks and extension. Furthermore, the thin device and thin pool usage match up exactly so there is no caching issue here between different layers. The thin device also does not seems to be reporting a failed status.

The logs might help clarify exactly what is happening.

jbaublitz Jan 17, 2022
Maintainer

And just to make sure: have you modified the storage stack at all outside of Stratis?

erickj · 2022-01-17T21:28:29Z

erickj
Jan 17, 2022
Author

re: logs

https://gist.github.com/erickj/c71578ade417c12448104f3216b95ad3

I noticed when looking at them that the update I mentioned above (from fedora 34 ->. 35)... I actually updated from 33 -> 34 -> 35 in 2 back-to-back reboot cycles. I see in the logs that stratisd upgraded from 2.1.0 -> 2.4.3. Could this direct upgrade have caused any backward compatibility issues?

Other than that, no I have not made any modifications to any stratis storage structures, afaik.

5 replies

jbaublitz Jan 17, 2022
Maintainer

I saw some logs in the earlier logs entries about the filesystems being read-only. This would absolutely cause filesystem extension to fail. Are they still in read only mode?

jbaublitz Jan 17, 2022
Maintainer

One potential incompatibility was the migration of device nodes from /stratis to /dev/stratis and I do see some mentions of /stratis earlier on.

erickj Jan 17, 2022
Author

Are they still in read only mode?

that warning seems to have disappeared post 2.4.3 update

22:27:37 [erick@jupiter:~] 
$ grep "only" /tmp/stratisd.logs
Oct 24 01:47:00 jupiter stratisd[1340]:  WARN libstratis::engine::strat_engine::devlinks: unable to remove pool directory "/stratis/net.ejjohnson.home", reason Os { code: 30, kind: Other, message: "Read-only file system" }
Oct 24 01:47:00 jupiter stratisd[1340]:  WARN libstratis::engine::strat_engine::devlinks: unable to remove pool directory "/stratis/local.volatile", reason Os { code: 30, kind: Other, message: "Read-only file system" }
Oct 24 01:47:00 jupiter stratisd[1340]:  WARN libstratis::engine::strat_engine::devlinks: unable to remove pool directory "/stratis/io.vos", reason Os { code: 30, kind: Other, message: "Read-only file system" }
Oct 24 01:52:56 jupiter stratisd[1248]:  WARN libstratis::engine::strat_engine::devlinks: unable to remove pool directory "/stratis/io.vos", reason Os { code: 30, kind: Other, message: "Read-only file system" }
Oct 24 01:52:56 jupiter stratisd[1248]:  WARN libstratis::engine::strat_engine::devlinks: unable to remove pool directory "/stratis/net.ejjohnson.home", reason Os { code: 30, kind: Other, message: "Read-only file system" }
Oct 24 01:52:56 jupiter stratisd[1248]:  WARN libstratis::engine::strat_engine::devlinks: unable to remove pool directory "/stratis/local.volatile", reason Os { code: 30, kind: Other, message: "Read-only file system" }
Oct 24 01:57:01 jupiter stratisd[1197]:  WARN libstratis::engine::strat_engine::devlinks: unable to remove pool directory "/stratis/net.ejjohnson.home", reason Os { code: 30, kind: Other, message: "Read-only file system" }
Oct 24 01:57:01 jupiter stratisd[1197]:  WARN libstratis::engine::strat_engine::devlinks: unable to remove pool directory "/stratis/local.volatile", reason Os { code: 30, kind: Other, message: "Read-only file system" }
Oct 24 01:57:01 jupiter stratisd[1197]:  WARN libstratis::engine::strat_engine::devlinks: unable to remove pool directory "/stratis/io.vos", reason Os { code: 30, kind: Other, message: "Read-only file system" }
Oct 24 18:59:09 jupiter stratisd[6327]:  WARN libstratis::engine::strat_engine::devlinks: unable to remove pool directory "/stratis/io.vos", reason Os { code: 30, kind: Other, message: "Read-only file system" }
Oct 24 18:59:09 jupiter stratisd[6327]:  WARN libstratis::engine::strat_engine::devlinks: unable to remove pool directory "/stratis/net.ejjohnson.home", reason Os { code: 30, kind: Other, message: "Read-only file system" }
Oct 24 18:59:09 jupiter stratisd[6327]:  WARN libstratis::engine::strat_engine::devlinks: unable to remove pool directory "/stratis/local.volatile", reason Os { code: 30, kind: Other, message: "Read-only file system" }
Oct 25 22:37:41 jupiter stratisd[1355]:  WARN libstratis::engine::strat_engine::devlinks: unable to remove pool directory "/stratis/io.vos", reason Os { code: 30, kind: Other, message: "Read-only file system" }
Oct 25 22:37:41 jupiter stratisd[1355]:  WARN libstratis::engine::strat_engine::devlinks: unable to remove pool directory "/stratis/local.volatile", reason Os { code: 30, kind: Other, message: "Read-only file system" }
Oct 25 22:37:41 jupiter stratisd[1355]:  WARN libstratis::engine::strat_engine::devlinks: unable to remove pool directory "/stratis/net.ejjohnson.home", reason Os { code: 30, kind: Other, message: "Read-only file system" }
Nov 27 14:25:33 jupiter stratisd[1277]:  WARN libstratis::engine::strat_engine::devlinks: unable to remove pool directory "/stratis/local.volatile", reason Os { code: 30, kind: Other, message: "Read-only file system" }
Nov 27 14:25:33 jupiter stratisd[1277]:  WARN libstratis::engine::strat_engine::devlinks: unable to remove pool directory "/stratis/net.ejjohnson.home", reason Os { code: 30, kind: Other, message: "Read-only file system" }
Nov 27 14:25:33 jupiter stratisd[1277]:  WARN libstratis::engine::strat_engine::devlinks: unable to remove pool directory "/stratis/io.vos", reason Os { code: 30, kind: Other, message: "Read-only file system" }
Nov 27 17:07:50 jupiter stratisd[1473]:  WARN libstratis::engine::strat_engine::devlinks: unable to remove pool directory "/stratis/net.ejjohnson.home", reason Os { code: 30, kind: Other, message: "Read-only file system" }
Nov 27 17:07:50 jupiter stratisd[1473]:  WARN libstratis::engine::strat_engine::devlinks: unable to remove pool directory "/stratis/io.vos", reason Os { code: 30, kind: Other, message: "Read-only file system" }
Nov 27 17:07:50 jupiter stratisd[1473]:  WARN libstratis::engine::strat_engine::devlinks: unable to remove pool directory "/stratis/local.volatile", reason Os { code: 30, kind: Other, message: "Read-only file system" }
Nov 27 17:14:00 jupiter stratisd[1179]:  WARN libstratis::engine::strat_engine::devlinks: unable to remove pool directory "/stratis/net.ejjohnson.home", reason Os { code: 30, kind: Other, message: "Read-only file system" }
Nov 27 17:14:00 jupiter stratisd[1179]:  WARN libstratis::engine::strat_engine::devlinks: unable to remove pool directory "/stratis/local.volatile", reason Os { code: 30, kind: Other, message: "Read-only file system" }
Nov 27 17:14:00 jupiter stratisd[1179]:  WARN libstratis::engine::strat_engine::devlinks: unable to remove pool directory "/stratis/io.vos", reason Os { code: 30, kind: Other, message: "Read-only file system" }
Nov 29 16:41:02 jupiter stratisd[1211]:  WARN libstratis::engine::strat_engine::devlinks: unable to remove pool directory "/stratis/io.vos", reason Os { code: 30, kind: Other, message: "Read-only file system" }
Nov 29 16:41:02 jupiter stratisd[1211]:  WARN libstratis::engine::strat_engine::devlinks: unable to remove pool directory "/stratis/local.volatile", reason Os { code: 30, kind: Other, message: "Read-only file system" }
Nov 29 16:41:02 jupiter stratisd[1211]:  WARN libstratis::engine::strat_engine::devlinks: unable to remove pool directory "/stratis/net.ejjohnson.home", reason Os { code: 30, kind: Other, message: "Read-only file system" }
22:38:39 [erick

jbaublitz Jan 17, 2022
Maintainer

However, is it mounted as read only on your system? Is it mounted at all? The filesystem has to be mounted to be extended. I'm just trying to rule out all possibilities to get to the bottom of this. Thank you for bearing with me!

If this doesn't work, I'll consult with my team about potentially issuing a devicemapper command directly to see if it succeeds. There is a possibility that the extension of the devicemapper device is failing silently. We have fixed this problem in later versions of stratisd but 2.4.4 is still affected. If the command fails manually, we may get some more information on what's wrong and how to fix it.

erickj Jan 17, 2022
Author

Yes, it's mounted. (/mnt/nas-ro is a read-only bind mount of /mnt/nas, which is the stratis mount)

$ mount | grep mnt
/dev/mapper/stratis-1-8d86f3f68666490b99b0b5c6a5fc7986-thin-fs-e8071df3346a4753bda1524c84d037f9 on /mnt/io.vos_raw type xfs (rw,relatime,seclabel,attr2,inode64,logbufs=8,logbsize=32k,sunit=2048,swidth=2048,noquota,x-systemd.requires=stratisd.service)
/dev/mapper/stratis-1-7e18ddcd99244c92b926100a7498630b-thin-fs-779e3ab97b244bc496283ae2f21e8cad on /mnt/nas type xfs (rw,relatime,seclabel,attr2,inode64,logbufs=8,logbsize=32k,sunit=2048,swidth=2048,noquota,x-systemd.requires=stratisd.service)
/dev/mapper/stratis-1-7e18ddcd99244c92b926100a7498630b-thin-fs-779e3ab97b244bc496283ae2f21e8cad on /mnt/nas-ro type xfs (ro,relatime,seclabel,attr2,inode64,logbufs=8,logbsize=32k,sunit=2048,swidth=2048,noquota,x-systemd.requires=stratisd.service)

$ cat /etc/fstab
#
# /etc/fstab
# Created by anaconda on Thu Jan 31 19:00:35 2019
#
# Accessible filesystems, by reference, are maintained under '/dev/disk/'.
# See man pages fstab(5), findfs(8), mount(8) and/or blkid(8) for more info.
#
# After editing this file, run 'systemctl daemon-reload' to update systemd
# units generated from this file.
#
/dev/mapper/fedora-root /                       xfs     defaults,x-systemd.device-timeout=0 0 0
UUID=acc80c08-bc09-4da3-9bb8-3cba19a607f0 /boot                   ext4    defaults        1 2
/dev/mapper/fedora-swap swap                    swap    defaults,x-systemd.device-timeout=0 0 0

UUID=8bec6004-cfe7-4820-99c3-1a827d37ba7f /opt/volatile/tmp xfs defaults,x-systemd.requires=stratisd.service,nofail 0 0

UUID=e8071df3-346a-4753-bda1-524c84d037f9 /mnt/io.vos_raw xfs defaults,x-systemd.requires=stratisd.service,nofail 0 0
UUID=779e3ab9-7b24-4bc4-9628-3ae2f21e8cad /mnt/nas	  xfs defaults,x-systemd.requires=stratisd.service,nofail 0 0

# Read-Only bind mount /mnt/nas -> nas-ro for samba share access
/mnt/nas /mnt/nas-ro none defaults,bind,ro,x-systemd.requires=stratisd.service,nofail 0 0

erickj · 2022-01-17T22:32:04Z

erickj
Jan 17, 2022
Author

@jbaublitz - so I just did a dnf update and stratis upgraded to 3.0.2.

The volumes seemed to have resized on their own. This issue is solved from my perspective. Thank you

23:30:48 [erick@jupiter:~] 
$ journalctl -u stratisd.service | grep version | tail
Dec 15 16:36:40 jupiter stratisd[1535]: [2021-12-15T15:36:40Z INFO  stratisd::stratis::run] stratis daemon version 2.4.4 started
Dec 15 16:51:25 jupiter stratisd[1451]: [2021-12-15T15:51:25Z INFO  stratisd::stratis::run] stratis daemon version 2.4.4 started
Dec 15 16:58:57 jupiter stratisd[1516]: [2021-12-15T15:58:57Z INFO  stratisd::stratis::run] stratis daemon version 2.4.4 started
Dec 20 19:21:45 jupiter stratisd[1577]: [2021-12-20T18:21:45Z INFO  stratisd::stratis::run] stratis daemon version 2.4.4 started
Dec 22 14:16:13 jupiter stratisd[1470]: [2021-12-22T13:16:13Z INFO  stratisd::stratis::run] stratis daemon version 2.4.4 started
Dec 22 14:19:56 jupiter stratisd[1591]: [2021-12-22T13:19:56Z INFO  stratisd::stratis::run] stratis daemon version 2.4.4 started
Dec 24 13:37:20 jupiter stratisd[1418]: [2021-12-24T12:37:20Z INFO  stratisd::stratis::run] stratis daemon version 2.4.4 started
Jan 13 23:41:13 jupiter stratisd[3480433]: [2022-01-13T22:41:13Z INFO  stratisd::stratis::run] stratis daemon version 2.4.4 started
Jan 17 22:43:11 jupiter stratisd[1581]: [2022-01-17T21:43:11Z INFO  stratisd::stratis::run] stratis daemon version 3.0.2 started
Jan 17 22:45:28 jupiter stratisd[1448]: [2022-01-17T21:45:28Z INFO  stratisd::stratis::run] stratis daemon version 3.0.2 started
23:30:56 [erick@jupiter:~] 
$ df -h /mnt/nas /mnt/io.vos_raw/
Filesystem                                                                                       Size  Used Avail Use% Mounted on
/dev/mapper/stratis-1-7e18ddcd99244c92b926100a7498630b-thin-fs-779e3ab97b244bc496283ae2f21e8cad  2.0T  1.8T  283G  87% /mnt/nas
/dev/mapper/stratis-1-8d86f3f68666490b99b0b5c6a5fc7986-thin-fs-e8071df3346a4753bda1524c84d037f9  2.0T  1.0T  1.0T  51% /mnt/io.vos_raw

2 replies

erickj Jan 17, 2022
Author

this appears to have been available since 12/21/21 https://fedora.pkgs.org/35/fedora-updates-x86_64/stratisd-3.0.2-1.fc35.x86_64.rpm.html

jbaublitz Jan 18, 2022
Maintainer

That's great to hear! I suspected that this could be resolved in stratisd 3.0 largely because we've added some major improvements to the thin pool and filesystem handling. If you bump into anything like this again, please do file an issue because we will definitely want to attend to that immediately.

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

manual trigger for filesystem extension? #391

{{title}}

Replies: 4 comments 13 replies

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{editor}}'s edit

{{editor}}'s edit

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

Select a reply

manual trigger for filesystem extension? #391

erickj Jan 12, 2022

Replies: 4 comments · 13 replies

jbaublitz Jan 13, 2022 Maintainer

erickj Jan 13, 2022 Author

jbaublitz Jan 14, 2022 Maintainer

jbaublitz Jan 14, 2022 Maintainer

erickj Jan 14, 2022 Author

jbaublitz Jan 17, 2022 Maintainer

jbaublitz Jan 17, 2022 Maintainer

erickj Jan 17, 2022 Author

jbaublitz Jan 17, 2022 Maintainer

jbaublitz Jan 17, 2022 Maintainer

erickj Jan 17, 2022 Author

jbaublitz Jan 17, 2022 Maintainer

erickj Jan 17, 2022 Author

erickj Jan 17, 2022 Author

erickj Jan 17, 2022 Author

jbaublitz Jan 18, 2022 Maintainer

erickj
Jan 12, 2022

Replies: 4 comments 13 replies

jbaublitz
Jan 13, 2022
Maintainer

erickj
Jan 13, 2022
Author

jbaublitz Jan 14, 2022
Maintainer

jbaublitz Jan 14, 2022
Maintainer

erickj Jan 14, 2022
Author

jbaublitz Jan 17, 2022
Maintainer

jbaublitz Jan 17, 2022
Maintainer

erickj
Jan 17, 2022
Author

jbaublitz Jan 17, 2022
Maintainer

jbaublitz Jan 17, 2022
Maintainer

erickj Jan 17, 2022
Author

jbaublitz Jan 17, 2022
Maintainer

erickj Jan 17, 2022
Author

erickj
Jan 17, 2022
Author

erickj Jan 17, 2022
Author

jbaublitz Jan 18, 2022
Maintainer