#40 closed enhancement (fixed)
Alternative approach to tracking free blocks in btrees
| Reported by: | Olly Betts | Owned by: | Olly Betts |
|---|---|---|---|
| Priority: | low | Milestone: | 1.3.2 |
| Component: | Backend-Brass | Version: | SVN trunk |
| Severity: | minor | Keywords: | |
| Cc: | dcolish@… | Blocked By: | |
| Blocking: | Operating System: | All |
Description (last modified by )
Use chains of free blocks rather than a bitmap - then we can store many old revisions more cheaply (just the space they actually need, not a whole bitmap for each one too). Then readers use fcntl locking on a single byte corresponding to the revision they're using (bytes off the end of the file can be locked, and shared locks on read-only files are ok). Then a writer would only delete old revisions for which it could obtain an exclusive lock (otherwise it would preserve them).
The Btree manager is generally written with multiple old revisions in mind, so this shouldn't be a huge project.
Attachments (1)
Change History (13)
comment:1 by , 20 years ago
| Severity: | blocker → normal |
|---|---|
| Status: | new → assigned |
comment:2 by , 19 years ago
| Component: | other → Backend-Flint |
|---|
comment:3 by , 17 years ago
| op_sys: | other → All |
|---|---|
| rep_platform: | Other → All |
| Severity: | normal → enhancement |
| Version: | other → SVN HEAD |
comment:4 by , 17 years ago
| Priority: | high → low |
|---|
by , 17 years ago
| Attachment: | betterdebug.patch added |
|---|
Debug tracing tweaks to help investigate this
comment:5 by , 17 years ago
| attachments.isobsolete: | 0 → 1 |
|---|---|
| Operating System: | → All |
(From update of attachment 56) Gah! Attachment meant for a different bug. I hate bugzilla.
comment:7 by , 16 years ago
| Component: | Backend-Flint → Backend-Chert |
|---|---|
| Description: | modified (diff) |
Remarking for chert...
comment:8 by , 14 years ago
| Component: | Backend-Chert → Backend-Brass |
|---|---|
| Milestone: | → 1.2.x |
I'm intending to implement this as part of the new B-tree manager for brass.
comment:9 by , 14 years ago
In brass, there will be a single for each revision which is still valid, so the readers just need to lock the one they are using.
comment:10 by , 13 years ago
| Cc: | added |
|---|
comment:11 by , 12 years ago
| Milestone: | 1.2.x → 1.3.2 |
|---|
I have a patch implementing free lists instead of bitmaps now, which it should be feasible to land for 1.3.2.
The "betterdebug.patch" attachment seems to be unrelated to this ticket - I suspect it was aimed at a different ticket, but despite looking through the list of tickets, I failed to work out which one...
comment:12 by , 11 years ago
| Milestone: | 1.3.2 → 1.3.3 |
|---|
comment:13 by , 10 years ago
| Milestone: | 1.3.3 → 1.3.2 |
|---|---|
| Resolution: | → fixed |
| Status: | assigned → closed |
Reassigned to the flint backend.
The fcntl locking issue is now addressed (in flint).
I've also worked out how to update freelists atomically and cheaply.