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