linuxready

Please also consider to reduce your disclosure rights. As it is currently written in the TOS, it's too broad.

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

Indeed the TOS has been changed on 1st of october ! I haven't noticed it, has an email been sent to notify the users ?

Anyway it's much better now (except for the disclosure, which hasn't been changed). Thanks !

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

You are probably right, bad idea.

Where can I find the proper official procedure to replace a failed drive (i.e. which cannot be mounted anymore) in a RAID1 array (with 2 drives) ?

I found these 2 links: https://unix.stackexchange.com/questions/334228/btrfs-raid1-... https://unix.stackexchange.com/questions/227560/how-to-repla...

But it is written there that if 'replace' doesn't work, it can take up to 5 days using add/remove for only 100GB !

I haven't found any official procedure on the Btrfs wiki.

I'm not sure that I have understood.

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 ?

Do you have a link to this real bug ? It would be interesting to follow it until it is resolved.

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

Very interesting. Is it using VSS to backup on Windows ? Otherwise I don't see how it can really achieve a complete correct backup on Windows.

The best cross-platform backup tool I have found is Burp. However it doesn't backup to cloud.

Oh that's it then ! Thanks for the clarification.

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