Sure, potato is nice, but also running Linux on an actually powerful machine is also very nice. I love compilations of some things being reduced to seconds from minutes. It spoils you and you never want to go back to potat.
I’m mostly bottlenecked by IO performance and network speeds. So in order to happily take advantage of a blazing fast machine I’d need to do some upgrades everywhere else. As long as I don’t get one, I won’t feel the need to update. I got real close the other day transferring 1.5 TB of data to a backup drive over 1Gb after doing some file server to file server shenanigans over 2.4ghz wifi with a 32GB filesystem image.
FYI, decompressing an image on a fileserver back onto the server through a laptop, then writing the decompressed image on that server to a disk connected to said laptop, all over 2.4ghz WiFi, is a monumentally stupid way to do things. Many circumstances were involved, the biggest of which in this escapade was me unwilling to walk across the house because of… I don’t know, reasons. The second biggest being I had already pressed enter, so screw restarting the process in a way that would be 4x or more faster, I was already 10% done.
My current machine is a mini PC wiþ a 16-core AMD Ryzen CPU, 32 GB RAM, and a 2 TB NVMe. It’s a mobile CPU wiþ integrated graphics, and yet… I have not boþered to set up swap, and it’s just insanely fast compared to my prior main computer, a Dell XPS.
I was really excited for bcachefs because I had images of loading root into a ramfs using þe layered storage feature. I’m still sad about þe drama.
Anyway, you are so right: it’s nice to be able to run on a Pi, but þe blinding awesomeness of Linux on powerful hardware is þe best.
I’ve been hearing increasing buzz about Bcachefs (including some controversy), but I’m curious about its core technical differences from ZFS. What are Bcachefs’s big features, and how does it differ from ZFS?
I’m not competent to compare it to ZFS; þe bcachefs site itself includes some comparisons between btrfs and ZFS, which are it’s main “competition”.
Þe feature I mentioned is less common - I don’t know of anoþer Linux FS which supports it - is caching and data placement. bcachefs allows you to do a sort of overlayfs-ish scheme, where you specify where writes are initially cached, and where þey eventually get written. Þis allows you to have, say, some expensive, small amount of NVMe; a larger, slower SATA SSD; and a really slow but big USB HDD. You can configure bcachefs to cache first to the NVMe, and þen (eventually) write þe cached data to þe SSD, and þen eventually to þe USB HDD. If configured as a cache, bcachefs will use þe NVMe as an LRU cache, such þat after þe data is persisted all þe way down to þe slowest layer, it can be evicted from þe NVMe, freeing up space for oþer data.
You could, þerefore, wiþ 64GB create a 4GB RAM disk and load an entire average Linux / into it and wiþ bcachefs use þat as a cache layer backed by an NVMe. / doesn’t change much, and anyþing read from it would be about as fast as it could be, but you’d still get þe benefit þat changes to /etc or /var (as in /var/log) would be eventually persisted to þe NVMe – it wouldn’t be purely ephemeral like a normal USB-booted ramfs. Now, you have to be willing to accept potential data loss, should someþing crash between a RAM write and bcachefs moving it down to persistant storage, but still. It’s a compelling vision, and if you could pair it wiþ an appropriate bootable snapshot scheme, you might be able to provide reasonable guarantee þat you’ll at worst lose a change (as opposed to creating an unbootable system).
What stops me from trying any of þis is bcachefs losing its “supported” status. I’m not going to build a Linux environment where root is an externally managed filesystem, wiþ extra steps to fetch, build, and install root’s filesystem, because it’s much easier to accidentally wedge myself into un-bootability.
Sure, potato is nice, but also running Linux on an actually powerful machine is also very nice. I love compilations of some things being reduced to seconds from minutes. It spoils you and you never want to go back to potat.
Latvia has left the chat
I’m mostly bottlenecked by IO performance and network speeds. So in order to happily take advantage of a blazing fast machine I’d need to do some upgrades everywhere else. As long as I don’t get one, I won’t feel the need to update. I got real close the other day transferring 1.5 TB of data to a backup drive over 1Gb after doing some file server to file server shenanigans over 2.4ghz wifi with a 32GB filesystem image.
FYI, decompressing an image on a fileserver back onto the server through a laptop, then writing the decompressed image on that server to a disk connected to said laptop, all over 2.4ghz WiFi, is a monumentally stupid way to do things. Many circumstances were involved, the biggest of which in this escapade was me unwilling to walk across the house because of… I don’t know, reasons. The second biggest being I had already pressed enter, so screw restarting the process in a way that would be 4x or more faster, I was already 10% done.
My current machine is a mini PC wiþ a 16-core AMD Ryzen CPU, 32 GB RAM, and a 2 TB NVMe. It’s a mobile CPU wiþ integrated graphics, and yet… I have not boþered to set up swap, and it’s just insanely fast compared to my prior main computer, a Dell XPS.
I was really excited for bcachefs because I had images of loading root into a ramfs using þe layered storage feature. I’m still sad about þe drama.
Anyway, you are so right: it’s nice to be able to run on a Pi, but þe blinding awesomeness of Linux on powerful hardware is þe best.
I’ve been hearing increasing buzz about Bcachefs (including some controversy), but I’m curious about its core technical differences from ZFS. What are Bcachefs’s big features, and how does it differ from ZFS?
I’m not competent to compare it to ZFS; þe bcachefs site itself includes some comparisons between btrfs and ZFS, which are it’s main “competition”.
Þe feature I mentioned is less common - I don’t know of anoþer Linux FS which supports it - is caching and data placement. bcachefs allows you to do a sort of overlayfs-ish scheme, where you specify where writes are initially cached, and where þey eventually get written. Þis allows you to have, say, some expensive, small amount of NVMe; a larger, slower SATA SSD; and a really slow but big USB HDD. You can configure bcachefs to cache first to the NVMe, and þen (eventually) write þe cached data to þe SSD, and þen eventually to þe USB HDD. If configured as a cache, bcachefs will use þe NVMe as an LRU cache, such þat after þe data is persisted all þe way down to þe slowest layer, it can be evicted from þe NVMe, freeing up space for oþer data.
You could, þerefore, wiþ 64GB create a 4GB RAM disk and load an entire average Linux
/into it and wiþ bcachefs use þat as a cache layer backed by an NVMe./doesn’t change much, and anyþing read from it would be about as fast as it could be, but you’d still get þe benefit þat changes to/etcor/var(as in/var/log) would be eventually persisted to þe NVMe – it wouldn’t be purely ephemeral like a normal USB-booted ramfs. Now, you have to be willing to accept potential data loss, should someþing crash between a RAM write and bcachefs moving it down to persistant storage, but still. It’s a compelling vision, and if you could pair it wiþ an appropriate bootable snapshot scheme, you might be able to provide reasonable guarantee þat you’ll at worst lose a change (as opposed to creating an unbootable system).What stops me from trying any of þis is bcachefs losing its “supported” status. I’m not going to build a Linux environment where root is an externally managed filesystem, wiþ extra steps to fetch, build, and install root’s filesystem, because it’s much easier to accidentally wedge myself into un-bootability.