I know that Roon uses EXFAT to format Nucleus and Rock libraries but does Roon care about the format of an external SSD used to store backups? The reason I ask is because I recently migrated my core from a Nucleus to a NUC with Rock and I had a lot of trouble with the backup. Just wondering if there’s any opinion on this.
For the internal SSDs, ROCK uses the ext4 format of Linux because ROCK is based on the Linux kernel. For external USB (music or backup):
If you ever want to copy the backups off the backup disk (and not over the network, where it does not matter - in which case use ext4 as well), also use ext4 if you have Linux on other machines (or an ext4 driver for Windows or macOS), or use exFAT if you don’t
Thanks. What I get from this is it doesn’t really matter how the backup drive is formatted unless you need cross platform compatibility. So I guess my problems weren’t related to the format of the backup drive I was trying to use.
I don’t think your problems were, but I don’t know which format you used. However, it’s always a good idea on every operating system to use the file format that is best supported, its native one. For Linux that’s ext4 for most generic use cases.
exFAT is a bit of an exception because it is simple and easy to support for everyone - that’s its main point. It misses features but they are not very important for what it is supposed to do - external disks that are compatible with everything. You wouldn’t use it for an OS install.
The one really bad idea with ROCK is NTFS.
S’funny , I had all sort of issues and finally went NTFS as I am a Windows user
Not a blip since , may not be ideal but work . I don’t really want to recopy 70K files . If it ain’t broke …
What I’m most concerned about is the USB SSD I use for Roon backups. Music is stored on an internal SSD in the NUC so it’s formatted by ROCK. I’m pretty sure the USB SSD was formatted NTFS. Maybe I should reformat to exFAT. What do you think?
If you trust the reverse engineering skills of Linux developers to understand a proprietary and extremely complex file system, and ignore the many issues we have seen with NTFS drives not mounting now that RoonOS since build 254 is strict about this, OK. It’s still a bad idea to use NTFS under Linux for anything important despite the recent improvements
As I am using macOS, Windows and Linux, I’ve formatted my external hard drive’s as ExFat. I’ve never run into any problems.
I have 3 copies of the drive content elsewhere if it crashes I’ll reformat exFAT but until then I simply cannot face copying the 70K files back to the drive and then recreating 3 x BU as the files will almost certainly “Change” and need re-copying UGH
Yeah I get that. If you are diligent about removing the NTFS drive safely after attaching it to a Windows machine, don’t just unplug it from a running RoonOS, and are not too fussed if it is not mounted by the NUC after a power outage without first running a chkdsk on Windows, I suppose you’re probably safe. The ROCK docs are also just saying that if you start fresh, avoiding NTFS is recommended.
It’s just that in principle modern file systems are already super complex even if the design and code are open to the developer (the general agreement is that it takes about 10 years to mature a new file system) and having to reverse engineer a closed and proprietary system like NTFS makes it even harder by orders of magnitude. The new Linux NTFS driver as used in RoonOS is an amazing achievement and has made great strides, but it’s just always going to remain harder than either Linux-native and open file systems or simple ones like exFAT
Interesting , I may be persuaded.
Funnily enough my NUC is powered up and down 2 -3 time daily , with no ill effects.
As it happens it was plugged in 3 months ago and never touched since . I don’t remove it . I am always careful mounting and unmounting my external USB drives I use for BU
I may take you advice when I get a few days to do it , our power situation screws up copying , I can’t just leave a disc copying overnight like you might expect so copying and BU is done piece meal over several days hence I’m hesitant to start the process
That’s fine. If it is being powered down, the OS kernel shuts down its filesystem interactions first, sends the proper commands to the drive, and ensures that it is cleanly unmounted. The problem is to simply unplug it without warning while it’s running.
To remove the drive from a running system, Windows has the “safely remove hardware” procedure (and general-purpose Linux distributions have unmount commands). This allows the OS to to finish all disk interactions cleanly and to signal to the drive that it is going to be removed.
Removing an NTFS drive from Windows without doing this is not recommended either, and RoonOS doesn’t have this option. It may well go fine in most cases without damaging the file system, but even in the best case it leaves an “uncleanly removed” flag on the file system, and the new Linux kernel driver refuses to mount such file systems until they are cleaned, to avoid later corruption. It’s also why Windows may go through an automated chkdisk on the next boot if the system drive was uncleanly shut down e.g. by a power outage or Windows kernel crash.
There were lots of such cases on the forum after RoonOS build 254 becoming strict about this because of including the new Linux kernel with the new NTFS driver, where external NTFS disks would simply not be mounted because of previous unclean removal. And for good reasons because a file system in such an inconsistent state may well work for a while and then run into corruption at a later time.
And if unlucky, the drive may be written to while it gets unplugged (and this are not just user-initiated actions but OS actions) and the file system may get into a more serious inconsistent state right away. It may be not often but it sucks if it does, so best to avoid taking the chance
Thanks for the clear info
My NUC is “Tucked away and forgotten” , it’s only action is on and off . The drive will stay in place for ever !!
I am off on holiday tomorrow , I will consider transferring when I return