- stratis-devel - Fedora mailing-lists

Best way to measure available disk space not taken by a filesystem limit?
by refi64 20 May '25

20 May '25

I've been working on a slightly cursed (?) side project to try and tie together Stratis and topolvm, and I've hit a bit of a strange issue. I need some way to figure out "how much space is available in the pool" that *is not reserved by a filesystem size limit*, i.e. I want to find `total pool size - size limits of all filesystems - space used by metadata.` But how much space is used by the metadata? Originally, my algorithm was roughly: reserved_filesystem_space = sum(for each filesystem -> filesystem.size_limit - filesystem.used) pool_space_remaining = pool_space_total - pool_space_used - reserved_filesystem_space The idea here is that the pool already tells me how much space is actually in use, so I just need to add on the difference between that and the size limits. (Or to view it differently, the space used by metadata is the total used space - the space used by the filesystems.) This worked...until I tested with snapshots, at which point I realized that the pool space property being physical space means that it doesn't count copy-on-write data, which I do actually want to count for this use case! After some thinking, I realized that on stratis 3.7, I could get *the available pool size excluding metadata* from the metadata itself, summing thin_data_dev. Then, I can calculate my space remaining by summing all the size limits and subtracting it from the total summed thin_data_dev. My question is...is this roughly correct? It seems to make intuitive sense to just subtract the limits from the size of the thin data device, but I'm not confident that the thin data device is what I'm actually looking for.

2 4

Report of a Use-After-Free Vulnerability in libblkid-rs
by quitbug lab 16 Jan '25

16 Jan '25

Dear Stratis Storage Team, I hope this email finds you well. I am writing to report a potential Use-After-Free (UAF) vulnerability identified in the `libblkid-rs` library. Vulnerability Details: Library: libblkid-rs Type: Use-After-Free (UAF) Description: In the function below, this line of code `filename_cstring.map(|s| s.as_ptr()).unwrap_or(ptr::null_mut())` generates a dangling pointer as a parameter when calling libblkid_rs_sys::blkid_get_cache(), leading to a UAF vulnerability. ``` pub fn get_cache(filename: Option<&Path>) -> Result<Self> { let mut cache = ptr::null_mut(); let filename_cstring = match filename { Some(fname) => Some(CString::new(fname.to_str().ok_or(BlkidErr::InvalidConv)?)?), None => None, }; errno!(unsafe { libblkid_rs_sys::blkid_get_cache( &mut cache as *mut _, filename_cstring .map(|s| s.as_ptr()) .unwrap_or(ptr::null_mut()), ) })?; Ok(BlkidCache(cache, false)) } ``` Steps to Reproduce: 1. Compile the following code with `libblkid-rs = "0.3.2"`: ``` use libblkid_rs::BlkidCache; use std::path::Path; fn main() { let cache_file_path = Some(Path::new("/dev")); let cache = BlkidCache::get_cache(cache_file_path).expect("msg"); } ``` 2. Run the compiled code with Valgrind to observe the UAF issue. ``` ==3115644== 1 errors in context 1 of 1: ==3115644== Invalid read of size 1 ==3115644== at 0x487DEED: blkid_get_cache (in /usr/lib/x86_64-linux-gnu/libblkid.so.1.1.0) ==3115644== by 0x121A51: libblkid_rs::cache::BlkidCache::get_cache ( cache.rs:46) ==3115644== by 0x120971: test1::main (main.rs:8) ==3115644== by 0x12133A: core::ops::function::FnOnce::call_once ( function.rs:250) ==3115644== by 0x1209DD: std::sys::backtrace::__rust_begin_short_backtrace (backtrace.rs:152) ==3115644== by 0x1205F0: std::rt::lang_start::{{closure}} (rt.rs:195) ==3115644== by 0x13DF76: call_once<(), (dyn core::ops::function::Fn<(), Output=i32> + core::marker::Sync + core::panic::unwind_safe::RefUnwindSafe)> (function.rs:284) ==3115644== by 0x13DF76: do_call<&(dyn core::ops::function::Fn<(), Output=i32> + core::marker::Sync + core::panic::unwind_safe::RefUnwindSafe), i32> (panicking.rs:573) ==3115644== by 0x13DF76: try<i32, &(dyn core::ops::function::Fn<(), Output=i32> + core::marker::Sync + core::panic::unwind_safe::RefUnwindSafe)> (panicking.rs:536) ==3115644== by 0x13DF76: catch_unwind<&(dyn core::ops::function::Fn<(), Output=i32> + core::marker::Sync + core::panic::unwind_safe::RefUnwindSafe), i32> (panic.rs:358) ==3115644== by 0x13DF76: {closure#1} (rt.rs:174) ==3115644== by 0x13DF76: do_call<std::rt::lang_start_internal::{closure_env#1}, isize> ( panicking.rs:573) ==3115644== by 0x13DF76: try<isize, std::rt::lang_start_internal::{closure_env#1}> (panicking.rs:536) ==3115644== by 0x13DF76: catch_unwind<std::rt::lang_start_internal::{closure_env#1}, isize> ( panic.rs:358) ==3115644== by 0x13DF76: std::rt::lang_start_internal (rt.rs:174) ==3115644== by 0x1205C9: std::rt::lang_start (rt.rs:194) ==3115644== by 0x1209CD: main (in /rust/test-libblkid/test1/target/debug/test1) ==3115644== Address 0x4afb8f0 is 0 bytes inside a block of size 5 free'd ==3115644== at 0x483FB3B: free (vg_replace_malloc.c:985) ==3115644== by 0x122735: dealloc (alloc.rs:116) ==3115644== by 0x122735: <alloc::alloc::Global as core::alloc::Allocator>::deallocate (alloc.rs:269) ==3115644== by 0x122FCE: <alloc::boxed::Box<T,A> as core::ops::drop::Drop>::drop (boxed.rs:1678) ==3115644== by 0x122D48: core::ptr::drop_in_place<alloc::boxed::Box<[u8]>> (mod.rs:522) ==3115644== by 0x122C2F: core::ptr::drop_in_place<alloc::ffi::c_str::CString> (mod.rs:522) ==3115644== by 0x121D54: libblkid_rs::cache::BlkidCache::get_cache::{{closure}} (cache.rs:49) ==3115644== by 0x121DE8: core::option::Option<T>::map (option.rs:1113) ==3115644== by 0x121A33: libblkid_rs::cache::BlkidCache::get_cache ( cache.rs:48) ==3115644== by 0x120971: test1::main (main.rs:8) ==3115644== by 0x12133A: core::ops::function::FnOnce::call_once ( function.rs:250) ==3115644== by 0x1209DD: std::sys::backtrace::__rust_begin_short_backtrace (backtrace.rs:152) ==3115644== by 0x1205F0: std::rt::lang_start::{{closure}} (rt.rs:195) ==3115644== Block was alloc'd at ==3115644== at 0x483C7F5: malloc (vg_replace_malloc.c:442) ==3115644== by 0x15D1A0: alloc (alloc.rs:96) ==3115644== by 0x15D1A0: alloc_impl (alloc.rs:192) ==3115644== by 0x15D1A0: allocate (alloc.rs:254) ==3115644== by 0x15D1A0: try_allocate_in<alloc::alloc::Global> ( raw_vec.rs:474) ==3115644== by 0x15D1A0: with_capacity_in<alloc::alloc::Global> ( raw_vec.rs:420) ==3115644== by 0x15D1A0: with_capacity_in<u8, alloc::alloc::Global> ( raw_vec.rs:192) ==3115644== by 0x15D1A0: with_capacity_in<u8, alloc::alloc::Global> ( mod.rs:803) ==3115644== by 0x15D1A0: with_capacity<u8> (mod.rs:483) ==3115644== by 0x15D1A0: spec_new_impl_bytes (c_str.rs:283) ==3115644== by 0x15D1A0: <&str as alloc::ffi::c_str::CString::new::SpecNewImpl>::spec_new_impl (c_str.rs:302) ==3115644== by 0x122DCA: alloc::ffi::c_str::CString::new (c_str.rs:312) ==3115644== by 0x121AA6: libblkid_rs::cache::BlkidCache::get_cache ( cache.rs:42) ==3115644== by 0x120971: test1::main (main.rs:8) ==3115644== by 0x12133A: core::ops::function::FnOnce::call_once ( function.rs:250) ==3115644== by 0x1209DD: std::sys::backtrace::__rust_begin_short_backtrace (backtrace.rs:152) ==3115644== by 0x1205F0: std::rt::lang_start::{{closure}} (rt.rs:195) ==3115644== by 0x13DF76: call_once<(), (dyn core::ops::function::Fn<(), Output=i32> + core::marker::Sync + core::panic::unwind_safe::RefUnwindSafe)> (function.rs:284) ==3115644== by 0x13DF76: do_call<&(dyn core::ops::function::Fn<(), Output=i32> + core::marker::Sync + core::panic::unwind_safe::RefUnwindSafe), i32> (panicking.rs:573) ==3115644== by 0x13DF76: try<i32, &(dyn core::ops::function::Fn<(), Output=i32> + core::marker::Sync + core::panic::unwind_safe::RefUnwindSafe)> (panicking.rs:536) ==3115644== by 0x13DF76: catch_unwind<&(dyn core::ops::function::Fn<(), Output=i32> + core::marker::Sync + core::panic::unwind_safe::RefUnwindSafe), i32> (panic.rs:358) ==3115644== by 0x13DF76: {closure#1} (rt.rs:174) ==3115644== by 0x13DF76: do_call<std::rt::lang_start_internal::{closure_env#1}, isize> ( panicking.rs:573) ==3115644== by 0x13DF76: try<isize, std::rt::lang_start_internal::{closure_env#1}> (panicking.rs:536) ==3115644== by 0x13DF76: catch_unwind<std::rt::lang_start_internal::{closure_env#1}, isize> ( panic.rs:358) ==3115644== by 0x13DF76: std::rt::lang_start_internal (rt.rs:174) ==3115644== by 0x1205C9: std::rt::lang_start (rt.rs:194) ==3115644== by 0x1209CD: main (in /rust/test-libblkid/test1/target/debug/test1) ``` Suggested Fix: Change this line of code `filename_cstring.map(|s| s.as_ptr()).unwrap_or(ptr::null_mut())` into `filename_cstring.as_ref().map(|s| s.as_ptr()).unwrap_or(ptr::null_mut())` Please let me know if you need any further information or assistance. Thank you for your attention to this issue. Best regards, Quitbug

1 0

Stratis 3.7
by the Mulhern 24 Oct '24

24 Oct '24

Hi! Stratis 3.7 has been released. It includes stratis-cli 3.7.0 and stratisd 3.7.3. Please see the blog post[1] for details. Thanks for your continued interest in the Stratis project. - mulhern [1] https://stratis-storage.github.io/stratis-release-notes-3-7-2/

1 0

StratisD question on version
by Zang (US), Tyler J 18 Sep '24

18 Sep '24

Hello there, I am running into an issue with StratisFS that I believe is a bug that has been corrected. What is the latest RHEL8 version of stratisd? More Info: I created a pool of 145TB over two devices, and then created filesystems on top of that. They seem to be maxing out at 4TB even though my xfs_quota are set to 9.5TB (soft) limits. I have exhausted my xfs_quota troubleshooting and it looks like this may have been seen before on the stratis side of things (https://bugzilla.redhat.com/show_bug.cgi?id=2007018#c4) Ty Zang * Cell: 562-266-8844 | * Desk: 562-797-1498 | Tyler.J.Zang(a)boeing.com<mailto:Tyler.J.Zang@boeing.com> The Boeing Company (Bldg 52-880.2 / 890.3) | BDS Versatile Technologist 4 (General Infrastructure) | Specialized US Infra Ops | ESG Schedule: (9/80) The data in this message is considered unclassified information as this is an unclassified system. Please refrain from discussing any classified discussion in this e-mail thread.

2 2

stratisd 3.6.8
by the Mulhern 08 Jul '24

08 Jul '24

Hi! stratisd 3.6.8 has been released. This release contains a fix to a bug where D-Bus signals when the filesystem Used property changed were not being sent out correctly. Please see the changelog[1] for this release for additional details. Thanks for your continued interest in the Stratis project. - mulhern [1] https://github.com/stratis-storage/stratisd/blob/patch-3.6.0/CHANGES.txt

2 1

stratisd 3.6.7
by the Mulhern 19 Apr '24

19 Apr '24

Hi! stratisd 3.6.7 has been released. Please see the blog post[1] for details. Please see the changelog[2] for this release for additional details. Thanks for your continued interest in the Stratis project. - mulhern [1] https://stratis-storage.github.io/stratisd-release-notes-3-6-7/ [2] https://github.com/stratis-storage/stratisd/blob/patch-3.6.0/CHANGES.txt

1 0

stratisd 3.6.5
by the Mulhern 26 Feb '24

26 Feb '24

Hi! stratisd 3.6.5 has been released. Please see the blog post[1] for details. Please see the changelog[2] for this release for additional details. Thanks for your continued interest in the Stratis project. - mulhern [1] https://stratis-storage.github.io/stratisd-release-notes-3-6-5/ [2] https://github.com/stratis-storage/stratisd/blob/patch-3.6.0/CHANGES.txt

1 0

Multi mount?
by Wags 12 Feb '24

12 Feb '24

Does Stratis support being mounted on multiple systems without corruption? IE, storage is exported via a fibre channel SAN array

2 2

stratis questions and support
by marcello.gambetti＠staff.aruba.it 07 Feb '24

07 Feb '24

Good afternoon, we are an italian csp, and i am evaluating stratis as tier storage solution, but i have some questions, can i ask you? 1. What happens when a generic new pool i create has 1TB space as default, but what happens when it reachs the 1TB limit? It is just a false limit? 2. Thin provisioning is great, but can i also trim the space once the files are deleted? Otherwise that filesystem will run out of space sooner or later. Thank you. ---------------------------------------------------------------------------- -------------------- Marcello Gambetti Engineering | Aruba Enterprise Email: marcello.gambetti(a)staff.aruba.it Mobile: (+39)348-2302308 UTC+2 (Rome time) enterprise.aruba.it | datacenter.it | arubaracing.it This message and its attachments are intended exclusively for the recipients. Any unauthorized use, communication or disclosure is strictly prohibited. If you have received this message in error, please delete it immediately and notify the sender.

2 1

stratisd 3.6.4
by the Mulhern 05 Feb '24

05 Feb '24

HI! stratisd 3.6.4 has been released. Please see the blog post[1] for details. Please see the changelog[2] for this release for additional details. Thanks for your continued interest in the Stratis project. - mulhern [1] https://stratis-storage.github.io/stratisd-release-notes-3-6-4/ [2] https://github.com/stratis-storage/stratisd/blob/patch-3.6.0/CHANGES.txt

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

stratis-devel