You actually don't need a shell script to mount the different pseudo filesystems. You can do that in your application. So all that remains is an initramfs with a statically linked binary.
For me the killer feature of btrfs is "RAID 1 with different sized disks".
For a small and cheap setup, this is perfect since a broken disk can be replaced with a bigger one and immediately (part of) the extra new disk space can be used. Other filesystems seem to only increase the size once all disks have been replaced with a bigger capacity one (last time I checked this was still the case for ZFS)
How does that work? You have two 100gb drives in raid1, 80% full, you replace one with a 200gb disk and write 50gb to the array - how is your 130gb of data protected against either drive failing?
I don't know the ins-and-outs of btrfs in detail, but having dug into other systems that offer redundancy-over-uneven-device-sizes and assuming btrfs is at least similar: with your two drive example you won't be able to write another 50gb to that array.
For two devices, 1x redundancy (so 2x copies of everything) will always limit your storage to the size of the smaller device otherwise it is not possible to have two copies of everything you need to store. As soon as you add a third device of at leats 100gb (or replace the 100gb device with one at least 200gb) the other 100gb of your second device will immediately come into play.
Uneven device size support is most useful when:
♯ You have three or more devices, or plan to grow onto three or more from an initial pair.
♯ You want flexibility rwt array growth (support for uneven devices usually (but not always) comes with better support for dynamic array reshaping).
♯ You want better quick repair flexibility: if 4Tb drive fails, you can replace it with 2x2Tb if you don't have a working 4Tb unit on-hand.
♯ You want variable redundancy (support for uneven devices sometimes comes with support for variable redundancy: keeping 3+ copies of important data, or data you want to access fastest via striping of reads, 2 copies of other permanent data, and 1 copy of temporary storage, all in the same array). In this instance the “wasted” part of the 200gb drive in your example could be used for scratch data designated as not needing to be stored with redundancy.
Traditional RAID1 will mirror whole drives, yes. BTRFS RAID1 will mirror chunks of data (iirc 1GB) on two drives. So you can have e.g. two 1TB drive and a 2TB one just fine.
You can do this with ZFS, you just have to do it manually, ie by partitioning up the disks in say 100GB or 1TB partitions, then construct vdevs using these partitions.
You can then extend the pool by adding more such partition-based vdevs as you replace disks, just add the new partitions and add new vdevs.
So if you have a 1TB disk, a 2TB disk and a 4 TB disk, you could have mirrors (d1p1,d3p1), (d2p1,d3p2), (d2p2,d3p3) with a total of 3TB mirrored, and 1 TB available. If you swap the 1TB for a 2TB disk, partition it, replacing the old d1p1 partition with the new and resilver, and once that's done you can add the mirror (d1p2,d3p4) and get the full 4TB redundant storage.
Not a great solution though, as it requires a lot of manual work, and especially write performance will suffer because ZFS will treat the vdevs as being separate and issue IOs in parallel to them, overloading the underlying devices.
Yeah, BTRFS is really not good for any sort of redundancy, not even very good for multi-disk in general.
1. The scheduler doesn't really exist. IIRC it is PID % num disks.
2. The default balancing policy is super basic. (IIRC always write to the disk with the most free space).
3. Erasure coding is still experimental.
4. Replication can only be configured at the FS level. bcachefs can configure this per-file or per-directory.
bcachefs is still early but it shows that it is serious about multi-disk. You can lump any collection of disks together and it mostly does the right thing. It tracks performance of different drives to make requests optimally and balances write to gradually even out the drives (not lasering a newly added disk).
IMHO there is really no comparison. If it wasn't for the fact that bcachefs ate my data I would be using it.
I agree, the dialogs are getting increasingly frequent and harder to "click" away.
I'm open for suggestions for an open-source Android image gallery app.
I've keep running Fedora coreos on my home server. My biggest issue with it, is that it is very cloud oriented and doesn't seem to allow to rerun the provisioning config on an already existing machine. This turns the thing again into a stateful pet instead of a "one cow cattle". Although I do very much like the rollback feature which has allowed me temporarily roll back an update a couple of times
> doesn't seem to allow to rerun the provisioning config on an already existing machine
In theory, a generic existing machine could have been compromised by malware, in which case the configuration may not match the previously provisioned version.
With OS launch integrity to guarantee absence of tampering, and prove that current=expected config+binaries, it could be feasible to rerun provisioning config.
I started valuing the enclosure that comes with the 10 dollar versions (e.g. the M5stack atom).
Since most use-cases for me are literally 1 sensor connected to an Atom, it (largely) fixes the enclosure problem. Although I'd like to have more DIN rail mounted options.
each year I make a year folder. And each project has a month + day prefix.
Sometimes I want long term projects to pop up on top, so I prefix them with 0000 (or only make the day 00).
It is simple, works on any OS. Although on Linux I do have some helper scripts.
And it is very easy to quickly make a directory and move files from downloads into this directory. Keeping the nesting only one level deep helps for the discoverability. (versus the YYYY/MM/DD pattern which uses an extra month level)
I do something similar for relevant folders, where I organize by time.
I have a top level dir where I usually have what I'm working on at the moment - think "this day" or "this week".
When it's time to archive it, outside that time window, I created a folder, using this format, for example for today:
041924
I move all the files I created on that day into there.
As a person with a typical human lifespan, I see no need to use a "2024" string - I don't think I'll live to see 2100, and anything before 2000 isn't relevant. "24" is just fine.
And that's it. Time keeps rolling on, so the number of 'archive' folders keeps increasing, but they're small in size and easy to locate.
This works really well when you're creating not-that-unique standard files every day, btw, which is my use case.
The advantage of 041924 is that, when changing directories from the terminal, you can type 0419 and tab the rest of the way (99% of the time the only completion is 24). It's more efficient. If I prepended the year, I'd have to type out 240419 every time.
My experience with metadata is that a lot of applications don't care about its integrity but will never mess with the filename unless that is the purpose of the application.
Demo a sync program and find that all the creation dates have changed to today!
> My experience with metadata is that a lot of applications don't care about its integrity [...]
This has led me to formally maintaining significant metadata in the filename, for certain kinds of files; everything else gets lost or diverges. For instance, a book file might be named `Title [a=Jim Smith; isbn=9781234567890].pdf`.
No, I'm serious. There's no portable filesystem metadata, and while a few kinds of media files have facilities for internal metadata (e.g. EXIF and ID3), most don't. A file name is the only non-content that is easy to keep associated with any kind of file.
The syntax is definitely an imperfect compromise, but most of the things I use this for have titles that frequently contain spaces (books, papers, music, etc.) so quoting would be necessary anyway, and I made myself a Python package to help with escaping and do other utility tasks like normalizing ISBNs.
that's a good idea, especially if you don't want to keep a database to manage your library. In the piracy side of things we just make sure to name files something that can be used to look it up in the database and get metadata from that.
Although I have to warn you that ISBNs are not a perfect guid and they sometimes get reissued. Good enough if you aren't hoarding the world I guess.
A lot of filesystems don't store file creation dates. Posix only requires last modification date (which for directories, is the last time a file/subdirectory was added, removed, or renamed), last access date, and last status change date.
I have a similar thing with the google photos app.
Almost every day it asks "You photos are not backed up, enable it now".
I say no (obviously).
Then it asks "But maybe you should backup these 100 images?" Pretty please?!
Clearly 100 images is enough to build a good profile.
Google photos are closed source. For all we know it could have analyzed all your photos locally and trickled the result to Google servers a thousand times by now.
Brother DCP-L2550DW here. One of the cheapest b/w multifunction devices with automatic document feeder and reasonable print and scan performance. Works like a charm on Linux, Windows, Android, and IOS.
I am using it with [NAPS2](https://www.naps2.com/), which is brilliantly simple, multi-platform, free, and open-source.
