Hacker News Reader

Comment by gnufied | Hacker News Reader

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.

View on HN

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?

Or you keep a local db of synced files and compare hashes

Not if you consider speed and CPU consumption.

And it getting out of sync with reality. Metadata on the files seems much better.

Yes, on file hashes for rename detection:

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).

I would assume the block size is at least 4k for anything created in this era.

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.

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.

Dropbox for Business is unlimited, isn't it?

No service is "unlimited". Its a marketing lie.

Why? Because there's always exceptions for 'abuse of service' and other exemptions.

The only time something is unlimited is if you do it yourself. Then you only have yourself to lean on.

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.

You still need to test. And I'm skeptical that there is no observable difference from the application level.

That certain subset seems to most likely to adapt their setups to just use ext4 if that's what's supported?

Then put a limit and don't claim unlimited

Bad for business. Better slap "unlimited" everywhere but just shoo away the hoarders.

Well assuming this paranoid reason for their move is true... (an assumption I don’t buy into) it would be more about churners than hoarders.

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.

Those same Linux users know they can just download rclone which is the client that has support for backblaze ;)

On their business plan, which bills for every GB (at a very good rate) but is commercialized at presumably a sustainable value right out the gate.

Reply on news.ycombinator.com