New releases: stratisd 0.5.3, stratis-cli 0.5.3, devicemapper 0.21.0, dbus-python-gen 0.3
by Andy Grover
Hi all,
We've just tagged some new releases. These continue to improve Stratis's
command-line experience, as well as laying the groundwork in stratisd
for some upcoming larger changes, working towards the 1.0 release.
Thanks!
stratisd 0.5.3:
Andy Grover <agrover(a)redhat.com> (11):
Move general startup tasks into main()
Thin out a comment a bit
Organize wrappers for command-line invocations
metadata: Establish SyncAll trait for metadata testing
Add static header size to test buffer used for BDA::initialize()
Change SyncAll::sync_all() to return io::Result
Remove some remaining flush() calls in favor of sync_all()
Move SyncAll trait and implementations to strat_engine/device.rs
fix travis fmt by pinning to 1.26.0
Use fallocate() to create backing files for loopback devs
Build against the lowest rustc version we claim to support
Igor Gnatenko <ignatenko(a)redhat.com> (1):
deps: update uuid to 0.6
Todd Gill <tgill(a)redhat.com> (1):
Add a test for thin pool transition back to "Good" when space is
added
Tony Asleson <tasleson(a)redhat.com> (3):
Use tempfile crate
Update compiler & fmt versions
Re-work dbus permissions
mulhern <amulhern(a)redhat.com> (23):
Disable clippy test while clippy continues broken
Update to new version of clippy
Allow failures for lint task on the Python code
Directly use tempfile from crate
Omit a bunch of needless extern declarations
Pin dbus-python to 1.2.4
Have method in StratEngine implementation return StratBlockDevs
Update formatting for newest version of yapf
Make clippy task an allowed failure on Travis
Revert "Update formatting for newest version of yapf"
Attach setting blockdev id to Pool trait
Remove obsoleted allow(dead-code)
No longer pin rustfmt to v0.8.3
Remove rustfmt.toml
Reformat according to the new rustfmt defaults
pub modifier sweep
Comment device limits
Add a min size and a max size to DeviceLimits constructors
Extend loopbacked tests to specify an exact size
Move all of _managed_object.py into _implementation.py
Update all tests to use new dbus-client-gen API
Update dbus-client-gen requirement to 0.3 in setup.py
Run clippy as a cargo command
pyup-bot <github-bot(a)pyup.io> (2):
Pin tox to latest version 3.0.0
Pin yapf to latest version 0.21.0
devicemapper 0.21.0:
Andy Grover <agrover(a)redhat.com> (3):
Pin rustfmt to version shipped with 1.26.0
version 0.20.1
version 0.21.0
Todd Gill <tgill(a)redhat.com> (1):
Set pool default to error_if_no_space
Tony Asleson <tasleson(a)redhat.com> (2):
Clean up between unit tests
Add DmOptions builder
mulhern <amulhern(a)redhat.com> (16):
Implement Display for TargetTables
Alphabetize the phony targets, and add any missing ones
Add UML graph making ability to devicemapper-rs
Fix clippy transmute_ptr_to_ptr error
Temporarily allow all clippy cast_ptr_alignment errors
Disable clippy test until a fix is pushed
No longer allow failures for clippy
Make clippy an allowed failure on Travis CI
Run rustfmt-preview on Travis
Remove rustfmt.toml
Reformat according to new rustfmt-preview defaults
Do not cache
Use tempfile crate
Use clippy command
Allow clippy renamed-and-removed-lints error
Use fallocate
stratis-cli 0.5.3:
Andy Grover <agrover(a)redhat.com> (1):
version 0.5.3
mulhern <amulhern(a)redhat.com> (16):
Change update from false to all
Allow lint task to fail
Correct explanation of --propagate flag
When printing an EngineError print out the name of the return code
Get rid of dead Makefile targets
Remove coverage related pragmas
Pin dbus-python to 1.2.4
Update Python style remark
Fix up tests so that all expect StratisCliActionError
Also catch and process an AttributeError
Updates for new version of dbus-client-gen
Now catch dbus-client-gen errors as appropriate
Tidy up generation code
Interpret all dbus-client-gen exceptions
Update dbus-client-gen requirement to 0.3
Catch all exception when trying to interpret an error
pyup-bot <github-bot(a)pyup.io> (2):
Pin yapf to latest version 0.21.0
Update tox from 2.9.1 to 3.0.0
dbus-client-gen 0.3:
mulhern <amulhern(a)redhat.com> (20):
Set up formatting task and reformat
Do not disable any pylint warnings or errors
Add view target to Makefile
Restrict the scope of a pylint decoration
Simplify hash table lookup
Ignore a few more files
Be more Pythonic when checking inclusion in a dict
Use Hypothesis to generate introspection data
Substitute GenerationErrors for RuntimeErrors where appropriate
Hoist build_property method out of builder method
Store only the part of the GMO result corresponding to the given
interface
Do not check that keys are subset of interface keys
Require RuntimeError to always have an interface name
Add several subclasses of RuntimeError
Refine some tests to be more meaningful and comprehensible
Allow to specify min, max child elements for interface strategy
Add new GMOQuery class
Add new DbusClientUnknownSearchPropertiesError
Modify mo_query_builder so that it returns a GMOQuery object
New version: 0.3
pyup-bot <github-bot(a)pyup.io> (2):
Pin tox to latest version 3.0.0
Pin yapf to latest version 0.21.0
5 years
Using LVM2 = questionable design choice
by Tao Effect
Dear list,
I've been researching ZFS and in the process stumbled upon Stratis and its Software Design paper [1].
The conclusion reads:
> Based on looking at the existing available building blocks, the best option is to build Stratis as a new project that initially makes use of XFS and device-mapper in its implementation. In parallel, request enhancements to LVM2 to enable its substitution for device-mapper when the enhancements are implemented. This lets Stratis proceed without delay to a point where it can be placed in prospective users’ hands to start getting feedback, and will allow Stratis to eventually use LVM2, and avoid duplicating functionality that LVM2 already provides.
I must same that I am very dismayed and disappointed to read that LVM is being considered at all, given the existence of ZFS, when the point of Stratis seems to be an extremely convoluted way of trying to replicate the excellent design of ZFS without using ZFS because of obscure licensing fears.
LVM is a usability nightmare compared to ZFS [2].
I think it is great that Stratis at least pushes the envelope in some way by choosing Rust as its implementation language.
However, why should anyone be excited about the prospect of using a system that is designed to be inferior to ZFS?
Why is all of this effort being poured into an inferior system design?
ZFS certainly has its problems (its installation is currently a nightmare thanks to lack of distro support), but software architecture design and usability do not seem to be one of them.
I wish Linux distributions had something like ZFS, whether that comes in the form of Stratis or something else. ZFS has been around for 13 years and still nothing has come close to beating it.
I urge this list to avoid expending effort on anything below the standard that ZFS has set.
- Greg
[1] https://stratis-storage.github.io/StratisSoftwareDesign.pdf <https://stratis-storage.github.io/StratisSoftwareDesign.pdf>
[2] https://www.agileweboperations.com/zfs-vs-lvm-for-dummies <https://www.agileweboperations.com/zfs-vs-lvm-for-dummies>
--
Please do not email me anything that you are not comfortable also sharing with the NSA.
5 years, 2 months