Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Limit blocks files to 256KiB boundaries #2122

Closed
ottuzzi opened this issue Dec 23, 2015 · 11 comments
Closed

Limit blocks files to 256KiB boundaries #2122

ottuzzi opened this issue Dec 23, 2015 · 11 comments
Labels
need/community-input Needs input from the wider community

Comments

@ottuzzi
Copy link

ottuzzi commented Dec 23, 2015

Hi,

I'm playing a bit with ipfs and I noted that files inside blocks directory are a bit bigger than 256KB.
I'm on go 1.5.2-win32 and I just built ipfs from github repo.
Files in blocks directory are 262.158 bytes but on disk they use 266.240 bytes: 256KB are exactly 262.144 bytes so for 14 bytes we use a 4KB more.
This is not only a "problem" for used space on disk (about 1.5% more) but it is not optimized for disk reads as we have to read 4KB more for only 14bytes. Probably all modern FS will take care of that but it will be nice if we can constraint us to exactly 262.144 bytes.

Bye
Piero

@Kubuxu
Copy link
Member

Kubuxu commented May 31, 2016

This is something that should be thought about while implementing IPLD as we will break hashes either way.

CC @mildred @whyrusleeping @jbenet

@mildred
Copy link
Contributor

mildred commented Jun 15, 2016

This is to take in consideration when chunking files to fit in multiple blocks. It doesn't have to do with IPLD directly. But you are right, we can use the IPLD transition to change the chunking algorithm as well.

@Kubuxu Kubuxu changed the title Limit blocks files to 256KB boundaries Limit blocks files to 256KiB boundaries Jun 15, 2016
@Kubuxu
Copy link
Member

Kubuxu commented Jun 15, 2016

We should also place limits on creating blocks (sanity check), maybe also on receiving them from the network (only if they are in IPLD format for backward compatibility)

Note: In Windows world 4kB means 4KiB, so the cluster size on windows is: 4 * 2^10.
Then our blocks should also be 256KiB in size, 256 * 2^10 = 262,144

@davidar
Copy link
Member

davidar commented Jun 15, 2016

@Kubuxu it usually means 4KiB on most platforms, no?

@Kubuxu
Copy link
Member

Kubuxu commented Jun 15, 2016

No, on darvin and Linux kB = 1000 bytes as for metric SI prefixes.

@davidar
Copy link
Member

davidar commented Jun 15, 2016

@Kubuxu what I mean is, afaik block sizes on linux are usually 4KiB too (they're just more explicit in distinguishing between KiB and kB than windows is)

@Kubuxu
Copy link
Member

Kubuxu commented Jun 15, 2016

Yeah, but as originator of the issue used kB, this indicated for me that he was using Windows, I had to check documentation to make sure that Windows (FAT and NTFS) is for sure using 4KiB cluster sizes (you know Windows, everything is possible).

@ottuzzi
Copy link
Author

ottuzzi commented Jun 15, 2016

Hi, I was thinking more at a disk layout level where last generation disks have a 4096bytes "sector" size :)

Bye
Piero

@whyrusleeping
Copy link
Member

This should be resolved when moving to ipld as it will allow us to reference raw blocks (without needed the extra framing)

@em-ly em-ly added the need/community-input Needs input from the wider community label Aug 25, 2016
@whyrusleeping
Copy link
Member

#3307 should fix this

@whyrusleeping
Copy link
Member

Using ipfs add --raw-leaves should acheive the goal of disk blocks being limited to exactly 256k

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
need/community-input Needs input from the wider community
Projects
None yet
Development

No branches or pull requests

6 participants