sometimes a helper hurts instead of helping (if you need to upload less than K shares) #613
Labels
No Label
0.2.0
0.3.0
0.4.0
0.5.0
0.5.1
0.6.0
0.6.1
0.7.0
0.8.0
0.9.0
1.0.0
1.1.0
1.10.0
1.10.1
1.10.2
1.10a2
1.11.0
1.12.0
1.12.1
1.13.0
1.14.0
1.15.0
1.15.1
1.2.0
1.3.0
1.4.1
1.5.0
1.6.0
1.6.1
1.7.0
1.7.1
1.7β
1.8.0
1.8.1
1.8.2
1.8.3
1.8β
1.9.0
1.9.0-s3branch
1.9.0a1
1.9.0a2
1.9.0b1
1.9.1
1.9.2
1.9.2a1
LeastAuthority.com automation
blocker
cannot reproduce
cloud-branch
code
code-dirnodes
code-encoding
code-frontend
code-frontend-cli
code-frontend-ftp-sftp
code-frontend-magic-folder
code-frontend-web
code-mutable
code-network
code-nodeadmin
code-peerselection
code-storage
contrib
critical
defect
dev-infrastructure
documentation
duplicate
enhancement
fixed
invalid
major
minor
n/a
normal
operational
packaging
somebody else's problem
supercritical
task
trivial
unknown
was already fixed
website
wontfix
worksforme
No Milestone
No Assignees
2 Participants
Notifications
Due Date
No due date set.
Reference: tahoe-lafs/trac-2024-07-25#613
Loading…
Reference in New Issue
Block a user
No description provided.
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
If #610 were fixed so that uploader (e.g. on repair) were smart about which shares to upload, then sometimes it would decide to upload only a single share, for example if the file were encoded with M=10 and 9 shares were already being served. If it were doing that, then uploading through a helper would ironically multiply the upstream bandwidth used instead of dividing it. So in that case it might want to be clever and skip using the helper.
sometimes a helper doesn't help (if you need to upload less than K shares)to sometimes a helper hurts instead of helping (if you need to upload less than K shares)I thought about this too. Without knowing too much about the internals, here is the idea:
Let's assume the helper knows (better) which shares to upload and which to reuse.
Couldn't an uploader
Additionally, if a share is unhappy, the helper could fetch it from a faster sever and re-distribute it (although it is probably a difficult decision if this is beneficial or not).
lpirl: what would be the point of the helper if the uploader was still doing erasure coding and uploading shares?
Sorry for not pointing that out clearly.
The idea is, that the uploader only uploads shares to the helper that are actually missing on the storage servers - or is it actually implemented this way?
In other words, the uploader would ask the helper if it needs a specific share prior uploading.
For shares that are available but unhappy, the helper could download and re-distribute them without requiring the client to upload them again.
lpirl: Happiness is currently a property of files, not of shares. (See https://github.com/zooko/tahoe-lafs/blob/1382-rewrite-5/docs/upload-happiness.rst for a new document about that.)
The point of the helper is to let the uploader avoid uploading all the shares, and instead upload just a copy of the ciphertext.
If there are only 1 or a few shares that need to be uploaded, then it would probably make more sense for the uploader to upload those shares directly to the servers, and not use the helper at all.