Subnostr

ZFS does to block and filesystems what wayland does to X and window managers, precisely the same pollution of two independent layers to the result of making a system so complex that it is both buggy still, after 20 years, and difficult to integrate with anything else, because of the way they both break the clean separation of concerns

there is eternal laws in this universe, and separation of concerns is one of them, and we are seeing the late stages of this abomination and iniquity and it will end soon because it is the road to hell

nostr:nevent1qvzqqqqqqypzq5455pmtewaacws6a73hxkqkea6fjwcm3keq9vqu3q7930nl4k9aqyghwumn8ghj7mn0wd68ytnvv9hxgtcpzemhxue69uhks6tnwshxummnw3ezumrpdejz7qgewaehxw309aex2mrp0yhxummnwa5x2un99e3k7mf0qy88wumn8ghj7mn0wvhxcmmv9uq32amnwvaz7tmjv4kxz7fwv3sk6atn9e5k7tcpzamhxue69uhhyetvv9ujumn0wd68ytnzv9hxgtcpz9mhxue69uhkummnw3ezuamfdejj7qgswaehxw309asjumn0wvhxcmmv9uq3jamnwvaz7tmrdsh8qatjwpkx2un9d3shjtnrdakj7qpqrwzrtfxjh3l9na9ejvy6ghtm3n0tnx6sx4nwtlaww2022egvasas03mzp6

Reply to this note

Please Login to reply.

Discussion

Ryan Wilkins 1y ago

This might not be pollution reasons but I encountered a problem with ZFS about six months ago where copying files and running a du command to find the number of blocks that the files use on disk would return the wrong value (low by a lot) if I ran it within a couple seconds of copying the files. Ext4 doesn’t exhibit this issue. This was causing issues with GitLab CI on a particular project that was using the blocks used on disk as a metric for creating a file system large enough to include the copied files. It took a while to figure that out and the eventual workaround was to make the CI runners run on ext4 on top of ZFS. I guess we could have modified the project code being compiled in CI to wait 5 or 10 seconds before getting the block count, but my thought was I shouldn’t have to modify the Makefile to workaround this issue.

semisol 1y ago

That is caused by the transaction system used by ZFS: all writes are committed in 5 second transactions, and before that the blocks reserved for the write and the original blocks for CoW are both “used”

This is kind of the shittier part of the FS, as it means sync writes run twice: one to the ZIL, and then to the actual disk.

ᴛʜᴇ ᴅᴇᴀᴛʜ ᴏꜰ ᴍʟᴇᴋᴜ 1y ago

i may literally lose my entire stack because of ZFS, shitty is not really quite sufficient

ᴛʜᴇ ᴅᴇᴀᴛʜ ᴏꜰ ᴍʟᴇᴋᴜ 1y ago

also should point out that it's lucky that i actually DID make a backup of my .bitcoin directory to an ext4 filesystem because there literally is no recovery methods for this

there is a tool that can search for bitcoin wallet.dat files, and i used it, and it found many possible candidates but the tool doesn't actually write the blocks anywhere that it finds the data on, idk even what this thing is fore tbh

but testdisk is finding filesystem header data all over this other disk that i'm pretty sure is where i just made a backup today, which should have the latest wallet.dat file and once i find that file and recover it, my ass is saved

but until then, i am in the waiting room for hell because if i've lost this wallet my life is rather difficult right now

Ryan Wilkins 1y ago

Makes sense. Thanks for the explanation.