4 ms·

The whole point of filesystems is they present the same interface. ZFS and ext4 should just work the same for Dropbox.

by wbl 8y ago

freedomben 8y ago
> The whole point of filesystems is they present the same interface. ZFS and ext4 should just work the same for Dropbox. This is unfortunately not true, especially with ZFS and ext4 that you mentioned. ZFS is different enough that you can't even use tools like `df` and `du`. You need to use the ZFS tools.
- userbinator 8y ago
  ZFS is different enough that you can't even use tools like `df` and `du`. I'm not as sure about df, but I've written a du or at least something approaching one before --- how does it not break every other application that relies on stat() and the file size that it returns?
  - cmurphycode 8y ago
    One reason for du/df problems with ZFS is ZFS compression.
- LeoPanthera 8y ago
  At least on FreeBSD, both those tools have been explicitly patched for ZFS. (See, for example, the -A switch to du.)
  - DannyB2 8y ago
    Your statement proves the point that developing for Linux means having to support many choices. What patches will be needed for yet some different filesystem, or init system, or desktop interface? And how many hundreds or thousands of programs might be affected?
roenxi 8y ago
In the main I agree, but 2 caveats here: 1) The interface cannot be magically guaranteed as appropriate. In this case, Dropbox implicitly believes they need capabilities that the standard filesystem interface is not providing. 2) If the differences between filesystems were not interesting, we wouldn't have different filesystems. ZFS and ext4 have to be different, and hence incompatible, in some interesting way, or why have both?
- Dylan16807 8y ago
  They have different performance metrics, they act differently when you unplug them, and they have different administrative features. Only the power loss scenario is something an application should ever care about, and even then it would either be "requires ZFS" or "doesn't care".
- userbinator 8y ago
  If the differences between filesystems were not interesting, we wouldn't have different filesystems. The differences between filesystems are largely implementation differences, not interface ones. They all essentially provide a way to store hierarchically named streams of bytes. If it was something like a formatter, fscker, defragger or similar utility I could definitely see the reason behind "only X filesystems are supported" --- they need to access the low-level data structures, but (disclaimer: haven't used it before) AFAIK all that Dropbox does is sync changes in files between your local filesystem and some cloud server --- which doesn't seem like the sort of functionality that requires anything more than the basic FS API. (If it hasn't already been done, someone should write their own client, or patch out a stupid check and show that, yes, Dropbox does work on just about any filesystem.)
  - pllbnk 8y ago
    I can talk from personal experience that usually one of the two problems appear when developing cross-platform products: 1. The documentation states that the API is 99% the same and should be sufficient to write most applications except the most advanced ones. And then you hit that one difference which is required for feature parity between platforms which requires either a small hack or a massive workaround which will have to be supported indefinitely. 2. Even if the APIs are the same, the performance characteristics of the systems are different because some of those systems might not be meant to satisfy the same use cases as others and different workarounds are required for cross-platform support. Dropbox desktop application might look simple from the outside, but it must contain some advanced features that its user base might require: directory exclusion from syncing, real-time file sync progress monitoring, displaying the UI status of the synchronization, real-time file change monitoring (as opposed to scanning the directory periodically for modification dates or content changes in the worst case) and many others I couldn't think of right now. So, basically, you can almost always find some open-source alternative for your needs but it will probably only be tested on one platform and will probably contain only a subset of features. I recently had a hard time finding a good enough implementation for Google Drive for Ubuntu.

The whole point of filesystems is they present the same interface. ZFS and ext4 should just work the same for Dropbox.

by wbl 8y ago

The whole point of filesystems is they present the same interface. ZFS and ext4 should just work the same for Dropbox.

> The whole point of filesystems is they present the same interface. ZFS and ext4 should just work the same for Dropbox. This is unfortunately not true, especially with ZFS and ext4 that you mentioned. ZFS is different enough that you can't even use tools like `df` and `du`. You need to use the ZFS tools.

userbinator 8y ago
ZFS is different enough that you can't even use tools like `df` and `du`. I'm not as sure about df, but I've written a du or at least something approaching one before --- how does it not break every other application that relies on stat() and the file size that it returns?
- cmurphycode 8y ago
  One reason for du/df problems with ZFS is ZFS compression.
LeoPanthera 8y ago
At least on FreeBSD, both those tools have been explicitly patched for ZFS. (See, for example, the -A switch to du.)
- DannyB2 8y ago
  Your statement proves the point that developing for Linux means having to support many choices. What patches will be needed for yet some different filesystem, or init system, or desktop interface? And how many hundreds or thousands of programs might be affected?

roenxi 8y ago

In the main I agree, but 2 caveats here: 1) The interface cannot be magically guaranteed as appropriate. In this case, Dropbox implicitly believes they need capabilities that the standard filesystem interface is not providing. 2) If the differences between filesystems were not interesting, we wouldn't have different filesystems. ZFS and ext4 have to be different, and hence incompatible, in some interesting way, or why have both?

Dylan16807 8y ago
They have different performance metrics, they act differently when you unplug them, and they have different administrative features. Only the power loss scenario is something an application should ever care about, and even then it would either be "requires ZFS" or "doesn't care".
userbinator 8y ago
If the differences between filesystems were not interesting, we wouldn't have different filesystems. The differences between filesystems are largely implementation differences, not interface ones. They all essentially provide a way to store hierarchically named streams of bytes. If it was something like a formatter, fscker, defragger or similar utility I could definitely see the reason behind "only X filesystems are supported" --- they need to access the low-level data structures, but (disclaimer: haven't used it before) AFAIK all that Dropbox does is sync changes in files between your local filesystem and some cloud server --- which doesn't seem like the sort of functionality that requires anything more than the basic FS API. (If it hasn't already been done, someone should write their own client, or patch out a stupid check and show that, yes, Dropbox does work on just about any filesystem.)
- pllbnk 8y ago
  I can talk from personal experience that usually one of the two problems appear when developing cross-platform products: 1. The documentation states that the API is 99% the same and should be sufficient to write most applications except the most advanced ones. And then you hit that one difference which is required for feature parity between platforms which requires either a small hack or a massive workaround which will have to be supported indefinitely. 2. Even if the APIs are the same, the performance characteristics of the systems are different because some of those systems might not be meant to satisfy the same use cases as others and different workarounds are required for cross-platform support. Dropbox desktop application might look simple from the outside, but it must contain some advanced features that its user base might require: directory exclusion from syncing, real-time file sync progress monitoring, displaying the UI status of the synchronization, real-time file change monitoring (as opposed to scanning the directory periodically for modification dates or content changes in the worst case) and many others I couldn't think of right now. So, basically, you can almost always find some open-source alternative for your needs but it will probably only be tested on one platform and will probably contain only a subset of features. I recently had a hard time finding a good enough implementation for Google Drive for Ubuntu.