I see the usual comment about Fastmail (comparison to Gmail, ProtonMail, web interface, spam filtering performance, servers in the US, ...) but still nothing about the TOS, which seems more important to me
So here it is again:
- Fastmail can immediately cancel your account for any reason: "The Service Provider may terminate your access to any part or all of the Service and any related service(s) at any time, with or without cause, with or without notice, effective immediately, for any reason whatsoever, with or without providing any refund of any payments."
- Fastmail can disclose your info/data if it thinks it's in the interest of the company: "The Service Provider will not monitor, edit, or disclose any personal information about you [...] unless required or allowed by law, or where the Service Provider has a good faith belief that such action is necessary to: [...] (2) protect and defend the rights or property of the Service Provider; [...] (4) act to protect the interests of its members or others [...]
By comparison, mailbox.org TOS are much better.
Also mailbox.org offers GPG encryption, which Fastmail doesn't (AFAIK).
No, that TOS was amended several months ago, to among other things, get rid of that clause about termination for any reason. "We used to be able to terminate your account at any time and for any reason. Now, we can only do so if you: fail to comply with the Terms and Conditions; if we are required to by law; or if your account is inactive for an extended period of time." [0] [1]
> - Fastmail can immediately cancel your account for any reason: "The Service Provider may terminate your access to any part or all of the Service and any related service(s) at any time, with or without cause, with or without notice, effective immediately, for any reason whatsoever, with or without providing any refund of any payments."
Other than the last clause about "without providing any refund", I would expect this from any service provider, and I'd certainly never want to run a service that didn't have this in its terms.
I do agree that the disclosure terms are more permissive than they should be.
>and I'd certainly never want to run a service that didn't have this in its terms.
that may make sense if it was for a free trial, or it was for a cat sharing app, but I certainly would not want my business to be dependent on a service that can be yanked away from me at any time.
>> - Fastmail can immediately cancel your account for any reason: "The Service Provider may terminate your access to any part or all of the Service and any related service(s) at any time, with or without cause, with or without notice, effective immediately, for any reason whatsoever, with or without providing any refund of any payments."
> Other than the last clause about "without providing any refund", I would expect this from any service provider, and I'd certainly never want to run a service that didn't have this in its terms.
You expect from any service that they can cancel your account for any reason ?!? We must not have the same set of requirements.
Anyway the point is not relevant anymore as they have changed the TOS (it's much better now).
> You expect from any service that they can cancel your account for any reason
Yes, absolutely. "We reserve the right to refuse service to anyone." I expect to be able to do that for any service I run, and I expect others to be able to do the same.
I also expect that doing so lightly, without a very well-justified reason, would get reported on and lead to a massive backlash. So, in practice, I expect such a clause to be used as, effectively, 'if you try to find a "creative" way to weasel your way out of our specific terms like "don't be disruptive, don't spam, etc", such that your activity meets the letter of the ToS but not the spirit, we'll kick you off anyway". Personally, if I were writing a ToS, I'd write the relevant term along those lines instead.
In almost all cases, we're very happy to provide refunds - particularly early in a subscription period. We also automatically refund if we believe accounts were opened with stolen credit details (happens more often than we would like despite all the checks in place at payment time).
There are plenty of instances of this bug being brought up on the mailing list. One of them is already linked elsewhere in this discussion, and the btrfs status page (also linked from this discussion) has further mailing list links.
Basically, btrfs doesn't want to allow a writeable mount when it might be missing some data. If there's some data on the FS that isn't stored with the RAID1 profile, then the kernel can't safely assume that the missing drive didn't have more chunks like that, holding data that wasn't mirrored on one of the surviving drives. But it's currently not possible to convert from RAID1 to non-RAID or to rebuild the array with a replacement without mounting the degraded array as writeable, which leads to non-RAID data being written. That puts the FS in a state that cannot be automatically judged safe at mount time, and the FS remains in that state until the recovery is complete (either converting from RAID1 to non-RAID, or replacing the failed drive).
There's no easy way to require the user to specify at the time of the `mount -o degraded,rw` whether they intend to resolve the situation by ceasing to use RAID1 or by replacing the failed drive. That leaves users with the opportunity to do neither and instead make the situation worse.
Thanks for the explanation. I was hoping for a Github issue number (or Bugzilla or whatever) to easily track this bug, but perhaps the Btrfs dev team doesn't work with issue number ?
At least for RAID1, it seems that implementing RAID1 N-way mirroring would ease the process to recover from a failed drive.
In case of drive failure, we could use the remaining drive in read-only mode to copy the data to a new drive, hence creating a RAID1 array with two working drives and one failed drive.
The OS should then allow to boot in rw mode, and from there it is easy to remove the failed drive from the RAID1 array.
However it seems that RAID1 N-way mirroring (with N > 2) is not even on the roadmap at this moment.
Have I misunderstood something or does this approach make sense ?
You can do RAID1 with more than two drives, but you'll only get two copies of each chunk of data. In this scenario, when one drive dies you can still write new data in RAID1 to the remaining space on the surviving drives, so mounting the FS writeable in degraded mode doesn't risk leaving the FS in a state where the safety is hard to determine on the next mount. If space permits, you can also rebalance before even shutting down to remove the failed drive, also avoiding the corner case.
Being able to do N-way mirroring with three or more copies of the data would be nice, but it's not necessary; 2-way mirroring across 3 or more drives is sufficient, and the hot spare feature will be more widely useful.
I was referring to this sequence of events:
1) 2-way mirroring across 2 drives
2) one drive fails
3) buy and plug a new drive
4) rebalance to have 3-way mirroring across 3 drives (with one being out): this is currently not possible
5) remove the failed drive, ending with 2-way mirroring across 2 drives
But it seems that you are referring to:
1) 2-way mirroring across 3 drives
2) one drive fails
3) rebalance to have 2-way mirroring across the 2 working drives
4) remove the failed drive, ending with 2-way mirroring across 2 drives
I assume that people don't/won't start the initial RAID1 with 3 drives.
Anyway, I would find 3-way mirroring across 3 drives very useful as it gives a simple identical foolproof process to replace a faulty hard drive, whether it has just a few corrupted data (but still readable) or have completely failed : just plug a new drive, rebalance, reboot and remove the defective drive.
> rebalance to have 3-way mirroring across 3 drives (with one being out): this is currently not possible
I'm not sure this even has meaning. But anyways, it's probably pointless to try to kick off a rebalance when the FS is still trying to use a dead drive. Either use the device replace command (which isn't stable yet), or tell btrfs to delete the dead drive then add the replacement drive. If the problem drive is failing but not completely dead yet, then the device replace command is supposed to move data over with a minimum of excess changes to drives other than the ones being removed and added. But the device replace command doesn't properly handle drives with bad sectors yet, so the separate remove and add actions are more reliable albeit slower and put more work on the other drives in the array.
I don't think Fastmail is very clear on their privacy policy (see also my other answer below).
Here is an extract from Fastmail TOS:
Fastmail can disclose your info/data if it thinks it's in the interest of the company: "The Service Provider will not monitor, edit, or disclose any personal information about you [...] unless required or allowed by law, or where the Service Provider has a good faith belief that such action is necessary to: [...] (2) protect and defend the rights or property of the Service Provider; [...] (4) act to protect the interests of its members or others [...]
Possible reasons (I'm also with Fastmail and it makes me uncomfortable):
- Fastmail can immediately cancel your account for any reason: "The Service Provider may terminate your access to any part or all of the Service and any related service(s) at any time, with or without cause, with or without notice, effective immediately, for any reason whatsoever, with or without providing any refund of any payments."
- Fastmail can disclose your info/data if it thinks it's in the interest of the company: "The Service Provider will not monitor, edit, or disclose any personal information about you [...] unless required or allowed by law, or where the Service Provider has a good faith belief that such action is necessary to: [...] (2) protect and defend the rights or property of the Service Provider; [...] (4) act to protect the interests of its members or others [...]
By comparison, mailbox.org TOS are much better.
Also mailbox.org offers GPG encryption, which Fastmail doesn't (AFAIK).
In this kind of scenario, I expect the block size to have only a marginal impact.
Indeed if all the CD ISOs are very similar, I would expect that the size of a duplicated chunk to be on average quite big.
The difference between using 128k and 64k for BTRFS is for instance not very big.
But except for the block size, I don't see other explanation for the differences.
Dedup is dedup, so I failed to understand why results between different implementation should lead to such differences at the end (except very incorrect implementation !).
The files on CDs are aligned to 2 kB boundaries. Dedup is looking for n kB continuous block. If the block size of the material you want to dedup does not match to the block size of dedup system, you'll get suboptimal results. The bigger the difference, the worse the results.
Say you have this data:
ABCABCBACCBBABCC
Dedup system that has block size of 1 can see you really have just three unique blocks, A, B and C.
Same data, but dedup with block size of 2:
AB CA BC BA CC BB AB CC
Dedup block size of 2 thinks you have 6 unique blocks: AB, CA, BC, BA, CC and BB.
I'm sorry I am not sure I get it.
Let's say you have a 1000 kB file which is duplicated and which is located on continuous blocks (so if the CDs used 2 kB boundaries, we'll have 500 continuous blocks).
If ZFS use 128 kB block size, it will detect 7 blocks (896 kB) that it can deduplicate. So we only lose about 10%.
Perhaps there is a high degree of fragmentation then and files are not on continous blocks ?
(this example would be the same if instead of 2 exactly duplicated files, we have a big common chunk between 2 files)
So here it is again:
- Fastmail can immediately cancel your account for any reason: "The Service Provider may terminate your access to any part or all of the Service and any related service(s) at any time, with or without cause, with or without notice, effective immediately, for any reason whatsoever, with or without providing any refund of any payments."
- Fastmail can disclose your info/data if it thinks it's in the interest of the company: "The Service Provider will not monitor, edit, or disclose any personal information about you [...] unless required or allowed by law, or where the Service Provider has a good faith belief that such action is necessary to: [...] (2) protect and defend the rights or property of the Service Provider; [...] (4) act to protect the interests of its members or others [...]
By comparison, mailbox.org TOS are much better.
Also mailbox.org offers GPG encryption, which Fastmail doesn't (AFAIK).