Nextcloud seems like a much better and automated solution, at least that’s what I’m planning to do with mine when I get it eventually.
This ridiculously easy solution is perfect. I have so much to learn. But DUH I didn’t realize I could get a USB C drive that could plug into either. LOL!!! THANK YOU and everyone!
My librem14 has a micro-sd card reader build right in 
2 Likes
yes, micro card reader and usb-c on mine
actually that brings up another option, the micro-sd reader is on both devices.
OK. I stand corrected. It’s not mentioned in the specs and I don’t own a Librem 14.
? That’s what I was suggesting that you do!
Yes, that is pretty cool. I have done that too.
However that is not a very practical way of making your music collection permanently available to the Librem 5 i.e. having a USB-C portable drive / flash drive hanging out the bottom. 
It is also a slower way of transferring files to a µSD card inside the Librem 5 - because the write speed that you will get with a decent card inside the Librem 5 is much lower than the write speed that you will get with the same card accessed on a reasonable desktop / laptop.
That’s fine just to add half a dozen new tracks but for the initial load of gigabytes of music it will be faster to use a µSD card as “sneakernet” i.e. put it in the desktop / laptop, load it up, move it to the Librem 5. (But then to add half a dozen new tracks, I would use the network.)
I’m definitely a fan of moving the card to fill it and then moving it back. I’ve done the same thing for music and even some photos I wanted to transfer from an old phone.
A couple of interesting notes: I didn’t see anywhere in the Librem 5 docs that it could read micros formatted with Btrfs, but I suspected it probably could; I figured, why not give the more updated FS a try if I’m starting from scratch anyway? The answer is yes, it has no problem with Btrfs. Contemplation question for the side note - I wonder if the JFS would use less power and result in a noticeably better battery life if accessing the micro a bunch?
Of course I didn’t notice that the GUI program I used to format it with automatically updated my fstab. I know I should’ve just used the terminal, but I was lazy and hadn’t tried that GUI feature yet. Sure it formatted the micro, but when I removed it and rebooted my computer quite some time later, fstab was very upset that it didn’t have the micro in anymore. It took me a while to realize what I had done and manually edit fstab, so try not to do that.
1 Like
It is difficult to keep up to date regarding which file systems are supported. You really need to get your kernel version and then refer to external docs.
There is a difference between what the kernel might support as root file system and what you might be able to support for another file system (such as via the µSD card reader).
You probably want either noauto or nofail - or mount via UUID. I understand that fstab got updated behind your back.
Yeah, I would have used the nofail if I actually wanted it, but I felt it was unnecessary in there, so I just removed the line completely.
This had not crossed my mind. I hope it’s unlikely to stop working if it’s working now.
What I mean is that the set of file system types that can be supported in a general context is very likely a proper superset of the set of file system types that can be supported as the root file system.
So while you might not be able to have exoticfs as the root file system, you might still be able to mount and use exoticfs as an additional file system i.e. on an additional drive (or partition).
1 Like
This is a journaling filesystem, isn’t it? If so, won’t your SD card will end up wearing out faster?
2 Likes
So… admittedly not being an expert, I’m pretty sure that ext4 is a journaling filesystem, which was the main one I was comparing it against. I think NTFS was too. I wasn’t sure about exFAT [checked now, and apparently it’s not], but that’s MS, and who wants that?
One of the main draws I had for Btrfs was… I’m sure I have something wrong i here but it’s how I interpreted what I read… it’s copy on write feature that helps avoid file corruption. It writes whole files before cleaning up old crap, which I took as - if my phone hiccups or its battery runs out before it’s done writing a file, it won’t have corrupted files by writing halfway over them before the operation was completed. Technically I think this makes it not a journaling file system? I don’t know if it reaps more havoc on the drive itself, but I understand people like it for faster read/write on SSDs. Not sure on lifetime though. Something for me to look up.
With ext4 you can disable the data journal, or you can move the journal to another device.
If it proves unsuitable then I think ext2 is non-journaling.
Journalling/copy-on-write won’t make anything faster, just more reliable. COW is like generalized journalling. The whole file system is the journal.
Personally, I don’t think speed or longevity from non-journalling is worth the risk of data loss, but you’d have to decide for yourself.
CoW can make copy faster and even save precious space.
cp --reflink --recursive repo backup
can “copy” ten thousands of files in an instant, by pointing the copies to the original content and only creating copies if either original or copy are modified.
With deduplication tools, the space saving aspect can even be achieved after the fact, although there are probably not many scenarios where this is really useful.
Back on topic, FAT file systems have the advantage of being readable by basically every device. PC, Camera, MP3 player …
That’s why I usually use them on thumb drives and SD cards, especially if I just put media files on them.
A related consideration is the difference between the soldered-in eMMC drive and a uSD card. If the latter dies then you throw it away, buy a new one and restore from backup. If the former dies then …
Honestly I think it would be difficult to quantify the real differences in file systems, with and without journalling where it is an option, as used on solid state media unless one can find reputable research.
Another consideration is number of reads v. number of writes. I have put my media on the uSD card, hence it is overwhelmingly “read”, so I don’t have to be too concerned about either journalling or corruption (or even data loss since it’s just a copy of what exists on the server).
I do recommend turning off atime though on solid state media unless you have a compelling need for it.
They do have significant disadvantages e.g. no reasonable security model, and lots of other ancient limitations (depending on exactly which FAT).
If compatibility with a camera, media player or other embedded device requires FAT then sure.
I wouldn’t use FAT for the uSD card to go in the Librem 5 unless there is a compelling need for that compatibility.
1 Like
Depends on the use case. It’s reasonable in the context of removable media: physical access = permission.
3 Likes
Big enough SD card has room to partition a LUKS-ext4 and a FAT - just in case you need to do an emergency physical transfer. And in the grand scheme of things, you should not trust a single device or disk, as they will brake (or be intentionally broken or lost) at some point anyway: separate backups (plural).
exFAT is no more proprietary, it is natively supported from kernel 5.4.