From @Mithgol on Wed Oct 14 2015 15:59:31 GMT+0000 (UTC)
Imagine a user that has ten terabytes of media files to share and those media files are located on different physical drives (four drives, for example: one 4 Tb HDD and three 2 Tb HDD).
Popular P2P applications such as µTorrent or eMule would be able to share these files from their initial locations.
IPFS intends to copy files to its local storage (as far as I understand) and thus creates limitations:
- Two copies of a file exist, and thus the necessary disk space is doubled.
- IPFS local storage is limited by the size of its physical drive.
Is that a problem? Can IPFS work around that problem?
Copied from original issue: https://github.com/ipfs/faq/issues/62
From @RichardLitt on Thu Mar 10 2016 19:11:17 GMT+0000 (UTC)
I’m not sure. @noffle, what do you think?
From @noffle on Thu Mar 10 2016 19:17:07 GMT+0000 (UTC)
My understanding is that we copy on add, and that a great deal of users would like if we did otherwise. We’re 100% interested in this happening. You can follow along in that discussion or suggest proposals for it on https://github.com/ipfs/go-ipfs/issues/875.
From @Kubuxu on Thu Mar 10 2016 19:26:12 GMT+0000 (UTC)
It would be awesome to detect modern Copy on Write filesystems and then use different datastore method. Copy whole file, thus freeze it content without really copping it, start chunking it in memory saving only hashes and file offsets. This way we can add files to IPFS without doubling storage requirements.