That statement is bit dubious. The next line also says:
> A supported file system is required as Dropbox relies on extended attributes (X-attrs) to identify files in the Dropbox folder and keep them in sync. We will keep supporting only the most common file systems that support X-attrs, so we can ensure stability and a consistent experience.
Certainly XFS supports xattr and hence ideally should be supported. I don't know why they singled out ext4. I am running Dropbox on ext4 LUKS encrypted partition and I haven't seen the warning yet.
I noticed Dropbox started setting their own xattrs on my files a year or two ago if I recall correctly.
My guess at the time was that they were using it for cheaper rename detection, using an xattr UUID, instead of using heuristics to compare {inode, btime, mtime, size, name, folder}.
In other words, they would match up the xattr UUID across CREATE and DELETE events to merge them into RENAME events.
Missing RENAME events is pretty bad for the user experience as it can lead to a loss of version history when the file ID changes through the DELETE, CREATE events.
Anyone have any other ideas as to why they would be reliant on xattrs?
It prevents a whole lot of pipeline and concurrency optimizations since it forces you to rehash every file in the change set, before your rename detection algorithm can kick in.
For example, if a user renames a root folder with tens of thousands of descendants, then the hash approach would have poor time-to-first-change-synced latency.
Furthermore, relying on file hashes won't actually work.
A user could have done both a RENAME and UPDATE on the file, since the sync app last ran (you need scanning logic for this, and can't rely solely on inotify). To survive a RENAME and UPDATE, you would then need to compare partial file hashes. But again, it affects latency too much.
extN xattrs are fairly limited, because iirc all xattrs of a given inode must be stored in the same block. I don't think XFS has any serious limitations (count/size) for them, but the Linux kernel itself limits the size to 64K.
You are correct. "man 5 attr" says:
In the current ext2, ext3, and ext4 filesystem implementations, the
total bytes used by the names and values of all of a file's extended
attributes must fit in a single filesystem block (1024, 2048 or 4096
bytes, depending on the block size specified when the filesystem was created).
Btrfs also has supported xattr since the start. It might be that they're dropping ecryptfs support which is file level encryption (blockdev>filesystem>encryption), whereas you're doing block level encryption with LUKS (blockdev>LUKS>filesystem). Since 2016, ext4 crypto and f2fs crypto were moved to VFS, open question if Dropbox will support that setup which is very common on recent Android versions.
It's because Linux users know what they're getting and store more data then "regular" users. It's the same reason "unlimited" storage plans from Backblaze don't have a Linux client.
Do you have any support for that claim? It seems incredibly unlikely that, say, Windows/Mac users don't store pictures, video, or music in their Dropbox folders and those are by far the most common way people use space in the modern era.
Yeah, this is probably about cutting out the big data users. They don't even offer an unlimited plan, but they probably noticed that certain linux users were using most of their 2tb plans while everyone else wasn't.
Lose the most active users, keep the ones paying for something they don't need.
Are you and XorNot guessing, or are you basing this off a statement they made?
Because the alternate explantation I assumed is that they don't want to continue maintaining a bunch of different filesystems. That complicates development quite a bit (because you need to have developers who know the quirks of the file systems) and testing a lot (because all changes have to be tested on all variants, and it becomes multiplicative when a platform has multiple file systems).
> the alternate explantation I assumed is that they don't want to continue maintaining a bunch of different filesystems.
But they don't have to maintain a bunch of different filesystems. That's the OS's job. From the application's PoV there shouldn't be any difference between these filesystems, all they need to do is check if the required feature (xattrs) is enabled for a certain FS and that's all.
Yeah this is not how it works. This is not how any of this works