Hacker News Reader

Comment by izacus | Hacker News Reader

The title is hugely misleading though - the j model documentation was always very specific that they can't support btrfs and you could never initialize the array into that mode. (At least it was when I was buying my Synology - and opted to + model which specifically supports it. This is the list devices Syno has with btrfs support: https://www.synology.com/en-global/knowledgebase/DSM/tutoria...)

The RAID array had to be moved from another device to work. Running your RAID array on a device that explicitly doesn't support it feels like a really risky behaviour.

View on HN

They still should've handled it differently. Show a warning to the user encouraging them to migrate, give a reasonable window before the feature is actually disabled, and don't let the users upgrade to a version which will break their storage.

Synology made a mistake which they admit:

> DSM incorrectly allowed administrators to migrate from a BTRFS-capable device and utilize previously created BTRFS volumes on the affected devices

And they're punishing users for it

Yeah, that's the crappy part. My intuition says that they didn't deliberately plan to remove it and it was a side effect of some firmware update cleanup.

What is the reason it cannot be 'supported' anyway? It clearly was possible. BTRFS has been mainlined for nearly as long as EXT4, and incurs no particular overheads compared to EXT4.

Whatever reason they chose to not support btrfs on their cheap ARM models. Might be stability, might just be pure market segmentation.

Cheapest models have insufficient RAM for btrfs.

It does not require more ram than ext4 in the configurations that DSM provides.

Source? How about cpu capabilities? Were they tested?

You're making the claim ;) The main thing an fs is, is a layout for data on disk after all, no mainline fs will do this in a way that is particularly consumptive of resources.

Specific features like RAID and deduplication are known to add to RAM and CPU requirements. Synology uses BTRFS for neither, so any performance differences are almost certainly not due to the specific fs.

I also have not seen any evidence of perf diffs.

If that were the case, then why did btrfs work perfectly on them all until this update?

> the j model documentation was always very specific that they can't support btrfs and you could never initialize the array into that mode

The problem was that the GUI didn't reflect that, which was the bug. And then they "fixed the bug" the same way that they "fixed the glitch" with Milton in Office Space

The GUI never allowed you to create such an array in the first place. If a user goes out of their way to put their storage array into an unsupported configuration, I get a lot less upset when the vendor makes that harder to do.

Even if it’s true, that GUI never allowed it (there’re people disputing it), migrating disks between different products from the same NAS manufacturer isn’t what I’d call going out of your way. It’s one of the reasons to stay loyal to the brand when you upgrade. If it’s incompatible, it should be rejected at the start, or changed later with tons of communication and proper checks (like blocking you from further sw upgrades until you migrate your array). Randomly breaking it is Synology going out of their way to hurt users.

Reply on news.ycombinator.com