zfs VS trash-cli

> The only non-junk PCIe3 option that's even advertised here recently is the overpriced WD Red SN700.

Those WD drives seem to have some real issues, at least with ZFS and btrfs. :(

https://github.com/openzfs/zfs/discussions/14793

IMO the "next fs" is just zfs. They somewhat recently merged RAIDZ expansion feature https://github.com/openzfs/zfs/pull/12225 and make regular improvements. If no file system has what you need today, zfs will probably be the first one to have it "tomorrow," imo.

https://github.com/openzfs/zfs/issues/15526#issuecomment-181...

> zpool get all tank | grep bclone

> kc3000 bcloneused 442M

> kc3000 bclonesaved 1.42G

> kc3000 bcloneratio 4.30x

> My understanding is this: If the result is 0 for both bcloneused and bclonesaved then it's safe to say that you don't have silent corruption.

A couple years ago, I had an idea for convincing a filesystem to go faster using 2 compression steps instead of one. I couldn't see why it wouldn't work, and I also couldn't convince myself it should.

It seems to have worked out. [1]

[1] - https://github.com/openzfs/zfs/commit/f375b23c026aec00cc9527...

https://github.com/openzfs/zfs/issues/7631

This is a long-standing issue with zvols which affects overall system stability, and has no real solution as of yet.

TIL. Thank you! https://github.com/openzfs/zfs/pull/15022

Difference may be significant, yes https://github.com/openzfs/zfs/pull/14243

There's a Freedesktop specification for trashing files that you may consider adhering to: https://specifications.freedesktop.org/trash-spec/trashspec-...

I get that writing a small utility is fun, but if it is just that (for fun), I suggest you put that into the readme. Otherwise, why should I choose your tool over something like https://github.com/andreafrancia/trash-cli, which seems to already be distributed for the major distros? Does your implementation scratch an itch that the myriad of other implementations don't? I'm just curious.

Hard deleting was more necessary on the past when storage was so tiny and expensive, but now we not constantly fighting for space anymore. So treat a rm (and the Unix tradition as a whole) as a product of its time, move undesirable files to the trash instead, you can use this trash-cli for linux.

Not related to Docker, but use the trash-cli trash command to have the recycle bin in the terminal as well.

i ended up using shell-safe-rm plus trash-cli and my own wrapper script around rm that verifies some rules like for example the argument don't start with '/' , if i want to delete for example /home/shin/.local/somefile then the script will not let me and suggest to cd to /home/me/.local and delete from there , same if i do rm /var/somedir.

They're probably talking about something like this rather than a GUI file manager

It's a bad idea to alias rm. You will get trouble on a machine that has no alias. Use trash-cli instead. It's much safer than rm. BTW, don't alias trash as rm because they are different.

For Linux there's [trash-cli](https://github.com/andreafrancia/trash-cli/). Doesn't seem to work for MacOS per this issue (https://github.com/andreafrancia/trash-cli/issues/284), but it suggests to use https://hasseg.org/trash/

Use trash-cli for all your rm -rf needs!

There are a number of foss tools that work with the freedesktop trashcan concept on Linuxes/BSDs, like https://github.com/andreafrancia/trash-cli. Bunch of desktop envs' programs also use this, so it's nearer to OS-wide standardized behavior.