-
-
Notifications
You must be signed in to change notification settings - Fork 3k
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
Comments
This is something that should be thought about while implementing IPLD as we will break hashes either way. |
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. |
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: |
@Kubuxu it usually means 4KiB on most platforms, no? |
No, on darvin and Linux |
@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) |
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). |
Hi, I was thinking more at a disk layout level where last generation disks have a 4096bytes "sector" size :) Bye |
This should be resolved when moving to ipld as it will allow us to reference raw blocks (without needed the extra framing) |
#3307 should fix this |
Using |
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
The text was updated successfully, but these errors were encountered: