2018-09-18 08:41:06 +00:00
|
|
|
// Copyright (C) 2018 The Syncthing Authors.
|
|
|
|
//
|
|
|
|
// This Source Code Form is subject to the terms of the Mozilla Public
|
|
|
|
// License, v. 2.0. If a copy of the MPL was not distributed with this file,
|
|
|
|
// You can obtain one at https://mozilla.org/MPL/2.0/.
|
|
|
|
|
|
|
|
package db
|
|
|
|
|
|
|
|
import (
|
|
|
|
"encoding/binary"
|
|
|
|
)
|
|
|
|
|
|
|
|
const (
|
|
|
|
keyPrefixLen = 1
|
|
|
|
keyFolderLen = 4 // indexed
|
|
|
|
keyDeviceLen = 4 // indexed
|
|
|
|
keySequenceLen = 8
|
|
|
|
keyHashLen = 32
|
|
|
|
|
|
|
|
maxInt64 int64 = 1<<63 - 1
|
|
|
|
)
|
|
|
|
|
|
|
|
const (
|
2018-12-10 08:55:04 +00:00
|
|
|
// KeyTypeDevice <int32 folder ID> <int32 device ID> <file name> = FileInfo
|
2020-06-17 07:37:07 +00:00
|
|
|
KeyTypeDevice byte = 0
|
2018-12-10 08:55:04 +00:00
|
|
|
|
|
|
|
// KeyTypeGlobal <int32 folder ID> <file name> = VersionList
|
2020-06-17 07:37:07 +00:00
|
|
|
KeyTypeGlobal byte = 1
|
2018-12-10 08:55:04 +00:00
|
|
|
|
|
|
|
// KeyTypeBlock <int32 folder ID> <32 bytes hash> <§file name> = int32 (block index)
|
2020-06-17 07:37:07 +00:00
|
|
|
KeyTypeBlock byte = 2
|
2018-12-10 08:55:04 +00:00
|
|
|
|
|
|
|
// KeyTypeDeviceStatistic <device ID as string> <some string> = some value
|
2020-06-17 07:37:07 +00:00
|
|
|
KeyTypeDeviceStatistic byte = 3
|
2018-12-10 08:55:04 +00:00
|
|
|
|
|
|
|
// KeyTypeFolderStatistic <folder ID as string> <some string> = some value
|
2020-06-17 07:37:07 +00:00
|
|
|
KeyTypeFolderStatistic byte = 4
|
2018-12-10 08:55:04 +00:00
|
|
|
|
|
|
|
// KeyTypeVirtualMtime <int32 folder ID> <file name> = dbMtime
|
2020-06-17 07:37:07 +00:00
|
|
|
KeyTypeVirtualMtime byte = 5
|
2018-12-10 08:55:04 +00:00
|
|
|
|
|
|
|
// KeyTypeFolderIdx <int32 id> = string value
|
2020-06-17 07:37:07 +00:00
|
|
|
KeyTypeFolderIdx byte = 6
|
2018-12-10 08:55:04 +00:00
|
|
|
|
|
|
|
// KeyTypeDeviceIdx <int32 id> = string value
|
2020-06-17 07:37:07 +00:00
|
|
|
KeyTypeDeviceIdx byte = 7
|
2018-12-10 08:55:04 +00:00
|
|
|
|
|
|
|
// KeyTypeIndexID <int32 device ID> <int32 folder ID> = protocol.IndexID
|
2020-06-17 07:37:07 +00:00
|
|
|
KeyTypeIndexID byte = 8
|
2018-12-10 08:55:04 +00:00
|
|
|
|
|
|
|
// KeyTypeFolderMeta <int32 folder ID> = CountsSet
|
2020-06-17 07:37:07 +00:00
|
|
|
KeyTypeFolderMeta byte = 9
|
2018-12-10 08:55:04 +00:00
|
|
|
|
|
|
|
// KeyTypeMiscData <some string> = some value
|
2020-06-17 07:37:07 +00:00
|
|
|
KeyTypeMiscData byte = 10
|
2018-12-10 08:55:04 +00:00
|
|
|
|
|
|
|
// KeyTypeSequence <int32 folder ID> <int64 sequence number> = KeyTypeDevice key
|
2020-06-17 07:37:07 +00:00
|
|
|
KeyTypeSequence byte = 11
|
2018-12-10 08:55:04 +00:00
|
|
|
|
|
|
|
// KeyTypeNeed <int32 folder ID> <file name> = <nothing>
|
2020-06-17 07:37:07 +00:00
|
|
|
KeyTypeNeed byte = 12
|
lib/db: Deduplicate block lists in database (fixes #5898) (#6283)
* lib/db: Deduplicate block lists in database (fixes #5898)
This moves the block list in the database out from being just a field on
the FileInfo to being an object of its own. When putting a FileInfo we
marshal the block list separately and store it keyed by the sha256 of
the marshalled block list. When getting, if we are not doing a
"truncated" get, we do an extra read and unmarshal for the block list.
Old block lists are cleared out by a periodic GC sweep. The alternative
would be to use refcounting, but:
- There is a larger risk of getting that wrong and either dropping a
block list in error or keeping them around forever.
- It's tricky with our current database, as we don't have dirty reads.
This means that if we update two FileInfos with identical block lists in
the same transaction we can't just do read/modify/write for the ref
counters as we wouldn't see our own first update. See above about
tracking this and risks about getting it wrong.
GC uses a bloom filter for keys to avoid heavy RAM usage. GC can't run
concurrently with FileInfo updates so there is a new lock around those
operation at the lowlevel.
The end result is a much more compact database, especially for setups
with many peers where files get duplicated many times.
This is per-key-class stats for a large database I'm currently working
with, under the current schema:
```
0x00: 9138161 items, 870876 KB keys + 7397482 KB data, 95 B + 809 B avg, 1637651 B max
0x01: 185656 items, 10388 KB keys + 1790909 KB data, 55 B + 9646 B avg, 924525 B max
0x02: 916890 items, 84795 KB keys + 3667 KB data, 92 B + 4 B avg, 192 B max
0x03: 384 items, 27 KB keys + 5 KB data, 72 B + 15 B avg, 87 B max
0x04: 1109 items, 17 KB keys + 17 KB data, 15 B + 15 B avg, 69 B max
0x06: 383 items, 3 KB keys + 0 KB data, 9 B + 2 B avg, 18 B max
0x07: 510 items, 4 KB keys + 12 KB data, 9 B + 24 B avg, 41 B max
0x08: 1349 items, 12 KB keys + 10 KB data, 9 B + 8 B avg, 17 B max
0x09: 194 items, 0 KB keys + 123 KB data, 5 B + 634 B avg, 11484 B max
0x0a: 3 items, 0 KB keys + 0 KB data, 14 B + 7 B avg, 30 B max
0x0b: 181836 items, 2363 KB keys + 10694 KB data, 13 B + 58 B avg, 173 B max
Total 10426475 items, 968490 KB keys + 9202925 KB data.
```
Note 7.4 GB of data in class 00, total size 9.2 GB. After running the
migration we get this instead:
```
0x00: 9138161 items, 870876 KB keys + 2611392 KB data, 95 B + 285 B avg, 4788 B max
0x01: 185656 items, 10388 KB keys + 1790909 KB data, 55 B + 9646 B avg, 924525 B max
0x02: 916890 items, 84795 KB keys + 3667 KB data, 92 B + 4 B avg, 192 B max
0x03: 384 items, 27 KB keys + 5 KB data, 72 B + 15 B avg, 87 B max
0x04: 1109 items, 17 KB keys + 17 KB data, 15 B + 15 B avg, 69 B max
0x06: 383 items, 3 KB keys + 0 KB data, 9 B + 2 B avg, 18 B max
0x07: 510 items, 4 KB keys + 12 KB data, 9 B + 24 B avg, 41 B max
0x09: 194 items, 0 KB keys + 123 KB data, 5 B + 634 B avg, 11484 B max
0x0a: 3 items, 0 KB keys + 0 KB data, 14 B + 17 B avg, 51 B max
0x0b: 181836 items, 2363 KB keys + 10694 KB data, 13 B + 58 B avg, 173 B max
0x0d: 44282 items, 1461 KB keys + 61081 KB data, 33 B + 1379 B avg, 1637399 B max
Total 10469408 items, 969939 KB keys + 4477905 KB data.
```
Class 00 is now down to 2.6 GB, with just 61 MB added in class 0d.
There will be some additional reads in some cases which theoretically
hurts performance, but this will be more than compensated for by smaller
writes and better compaction.
On my own home setup which just has three devices and a handful of
folders the difference is smaller in absolute numbers of course, but
still less than half the old size:
```
0x00: 297122 items, 20894 KB keys + 306860 KB data, 70 B + 1032 B avg, 103237 B max
0x01: 115299 items, 7738 KB keys + 17542 KB data, 67 B + 152 B avg, 419 B max
0x02: 1430537 items, 121223 KB keys + 5722 KB data, 84 B + 4 B avg, 253 B max
...
Total 1947412 items, 151268 KB keys + 337485 KB data.
```
to:
```
0x00: 297122 items, 20894 KB keys + 37038 KB data, 70 B + 124 B avg, 520 B max
0x01: 115299 items, 7738 KB keys + 17542 KB data, 67 B + 152 B avg, 419 B max
0x02: 1430537 items, 121223 KB keys + 5722 KB data, 84 B + 4 B avg, 253 B max
...
0x0d: 18041 items, 595 KB keys + 71964 KB data, 33 B + 3988 B avg, 101109 B max
Total 1965447 items, 151863 KB keys + 139628 KB data.
```
* wip
* wip
* wip
* wip
2020-01-24 07:35:44 +00:00
|
|
|
|
|
|
|
// KeyTypeBlockList <block list hash> = BlockList
|
2020-06-17 07:37:07 +00:00
|
|
|
KeyTypeBlockList byte = 13
|
2020-05-11 18:15:11 +00:00
|
|
|
|
|
|
|
// KeyTypeBlockListMap <int32 folder ID> <block list hash> <file name> = <nothing>
|
2020-06-17 07:37:07 +00:00
|
|
|
KeyTypeBlockListMap byte = 14
|
2020-05-13 12:28:42 +00:00
|
|
|
|
|
|
|
// KeyTypeVersion <version hash> = Vector
|
2020-06-17 07:37:07 +00:00
|
|
|
KeyTypeVersion byte = 15
|
2020-12-17 18:54:31 +00:00
|
|
|
|
|
|
|
// KeyTypePendingFolder <int32 device ID> <folder ID as string> = ObservedFolder
|
|
|
|
KeyTypePendingFolder byte = 16
|
|
|
|
|
|
|
|
// KeyTypePendingDevice <device ID in wire format> = ObservedDevice
|
|
|
|
KeyTypePendingDevice byte = 17
|
2018-09-18 08:41:06 +00:00
|
|
|
)
|
|
|
|
|
|
|
|
type keyer interface {
|
|
|
|
// device file key stuff
|
2019-11-29 08:11:52 +00:00
|
|
|
GenerateDeviceFileKey(key, folder, device, name []byte) (deviceFileKey, error)
|
2018-09-18 08:41:06 +00:00
|
|
|
NameFromDeviceFileKey(key []byte) []byte
|
|
|
|
DeviceFromDeviceFileKey(key []byte) ([]byte, bool)
|
|
|
|
FolderFromDeviceFileKey(key []byte) ([]byte, bool)
|
|
|
|
|
|
|
|
// global version key stuff
|
2019-11-29 08:11:52 +00:00
|
|
|
GenerateGlobalVersionKey(key, folder, name []byte) (globalVersionKey, error)
|
2018-09-18 08:41:06 +00:00
|
|
|
NameFromGlobalVersionKey(key []byte) []byte
|
|
|
|
|
2019-01-23 09:22:33 +00:00
|
|
|
// block map key stuff (former BlockMap)
|
2019-11-29 08:11:52 +00:00
|
|
|
GenerateBlockMapKey(key, folder, hash, name []byte) (blockMapKey, error)
|
2019-01-23 09:22:33 +00:00
|
|
|
NameFromBlockMapKey(key []byte) []byte
|
2020-05-11 18:15:11 +00:00
|
|
|
GenerateBlockListMapKey(key, folder, hash, name []byte) (blockListMapKey, error)
|
|
|
|
NameFromBlockListMapKey(key []byte) []byte
|
2019-01-23 09:22:33 +00:00
|
|
|
|
2018-09-18 08:41:06 +00:00
|
|
|
// file need index
|
2019-11-29 08:11:52 +00:00
|
|
|
GenerateNeedFileKey(key, folder, name []byte) (needFileKey, error)
|
2018-09-18 08:41:06 +00:00
|
|
|
|
|
|
|
// file sequence index
|
2019-11-29 08:11:52 +00:00
|
|
|
GenerateSequenceKey(key, folder []byte, seq int64) (sequenceKey, error)
|
2018-09-18 08:41:06 +00:00
|
|
|
SequenceFromSequenceKey(key []byte) int64
|
|
|
|
|
|
|
|
// index IDs
|
2019-11-29 08:11:52 +00:00
|
|
|
GenerateIndexIDKey(key, device, folder []byte) (indexIDKey, error)
|
2020-12-21 10:10:59 +00:00
|
|
|
FolderFromIndexIDKey(key []byte) ([]byte, bool)
|
2018-09-18 08:41:06 +00:00
|
|
|
|
|
|
|
// Mtimes
|
2019-11-29 08:11:52 +00:00
|
|
|
GenerateMtimesKey(key, folder []byte) (mtimesKey, error)
|
2018-09-18 08:41:06 +00:00
|
|
|
|
|
|
|
// Folder metadata
|
2019-11-29 08:11:52 +00:00
|
|
|
GenerateFolderMetaKey(key, folder []byte) (folderMetaKey, error)
|
lib/db: Deduplicate block lists in database (fixes #5898) (#6283)
* lib/db: Deduplicate block lists in database (fixes #5898)
This moves the block list in the database out from being just a field on
the FileInfo to being an object of its own. When putting a FileInfo we
marshal the block list separately and store it keyed by the sha256 of
the marshalled block list. When getting, if we are not doing a
"truncated" get, we do an extra read and unmarshal for the block list.
Old block lists are cleared out by a periodic GC sweep. The alternative
would be to use refcounting, but:
- There is a larger risk of getting that wrong and either dropping a
block list in error or keeping them around forever.
- It's tricky with our current database, as we don't have dirty reads.
This means that if we update two FileInfos with identical block lists in
the same transaction we can't just do read/modify/write for the ref
counters as we wouldn't see our own first update. See above about
tracking this and risks about getting it wrong.
GC uses a bloom filter for keys to avoid heavy RAM usage. GC can't run
concurrently with FileInfo updates so there is a new lock around those
operation at the lowlevel.
The end result is a much more compact database, especially for setups
with many peers where files get duplicated many times.
This is per-key-class stats for a large database I'm currently working
with, under the current schema:
```
0x00: 9138161 items, 870876 KB keys + 7397482 KB data, 95 B + 809 B avg, 1637651 B max
0x01: 185656 items, 10388 KB keys + 1790909 KB data, 55 B + 9646 B avg, 924525 B max
0x02: 916890 items, 84795 KB keys + 3667 KB data, 92 B + 4 B avg, 192 B max
0x03: 384 items, 27 KB keys + 5 KB data, 72 B + 15 B avg, 87 B max
0x04: 1109 items, 17 KB keys + 17 KB data, 15 B + 15 B avg, 69 B max
0x06: 383 items, 3 KB keys + 0 KB data, 9 B + 2 B avg, 18 B max
0x07: 510 items, 4 KB keys + 12 KB data, 9 B + 24 B avg, 41 B max
0x08: 1349 items, 12 KB keys + 10 KB data, 9 B + 8 B avg, 17 B max
0x09: 194 items, 0 KB keys + 123 KB data, 5 B + 634 B avg, 11484 B max
0x0a: 3 items, 0 KB keys + 0 KB data, 14 B + 7 B avg, 30 B max
0x0b: 181836 items, 2363 KB keys + 10694 KB data, 13 B + 58 B avg, 173 B max
Total 10426475 items, 968490 KB keys + 9202925 KB data.
```
Note 7.4 GB of data in class 00, total size 9.2 GB. After running the
migration we get this instead:
```
0x00: 9138161 items, 870876 KB keys + 2611392 KB data, 95 B + 285 B avg, 4788 B max
0x01: 185656 items, 10388 KB keys + 1790909 KB data, 55 B + 9646 B avg, 924525 B max
0x02: 916890 items, 84795 KB keys + 3667 KB data, 92 B + 4 B avg, 192 B max
0x03: 384 items, 27 KB keys + 5 KB data, 72 B + 15 B avg, 87 B max
0x04: 1109 items, 17 KB keys + 17 KB data, 15 B + 15 B avg, 69 B max
0x06: 383 items, 3 KB keys + 0 KB data, 9 B + 2 B avg, 18 B max
0x07: 510 items, 4 KB keys + 12 KB data, 9 B + 24 B avg, 41 B max
0x09: 194 items, 0 KB keys + 123 KB data, 5 B + 634 B avg, 11484 B max
0x0a: 3 items, 0 KB keys + 0 KB data, 14 B + 17 B avg, 51 B max
0x0b: 181836 items, 2363 KB keys + 10694 KB data, 13 B + 58 B avg, 173 B max
0x0d: 44282 items, 1461 KB keys + 61081 KB data, 33 B + 1379 B avg, 1637399 B max
Total 10469408 items, 969939 KB keys + 4477905 KB data.
```
Class 00 is now down to 2.6 GB, with just 61 MB added in class 0d.
There will be some additional reads in some cases which theoretically
hurts performance, but this will be more than compensated for by smaller
writes and better compaction.
On my own home setup which just has three devices and a handful of
folders the difference is smaller in absolute numbers of course, but
still less than half the old size:
```
0x00: 297122 items, 20894 KB keys + 306860 KB data, 70 B + 1032 B avg, 103237 B max
0x01: 115299 items, 7738 KB keys + 17542 KB data, 67 B + 152 B avg, 419 B max
0x02: 1430537 items, 121223 KB keys + 5722 KB data, 84 B + 4 B avg, 253 B max
...
Total 1947412 items, 151268 KB keys + 337485 KB data.
```
to:
```
0x00: 297122 items, 20894 KB keys + 37038 KB data, 70 B + 124 B avg, 520 B max
0x01: 115299 items, 7738 KB keys + 17542 KB data, 67 B + 152 B avg, 419 B max
0x02: 1430537 items, 121223 KB keys + 5722 KB data, 84 B + 4 B avg, 253 B max
...
0x0d: 18041 items, 595 KB keys + 71964 KB data, 33 B + 3988 B avg, 101109 B max
Total 1965447 items, 151863 KB keys + 139628 KB data.
```
* wip
* wip
* wip
* wip
2020-01-24 07:35:44 +00:00
|
|
|
|
|
|
|
// Block lists
|
|
|
|
GenerateBlockListKey(key []byte, hash []byte) blockListKey
|
2020-05-13 12:28:42 +00:00
|
|
|
|
|
|
|
// Version vectors
|
|
|
|
GenerateVersionKey(key []byte, hash []byte) versionKey
|
2020-12-17 18:54:31 +00:00
|
|
|
|
|
|
|
// Pending (unshared) folders and devices
|
|
|
|
GeneratePendingFolderKey(key, device, folder []byte) (pendingFolderKey, error)
|
|
|
|
FolderFromPendingFolderKey(key []byte) []byte
|
|
|
|
DeviceFromPendingFolderKey(key []byte) ([]byte, bool)
|
|
|
|
|
|
|
|
GeneratePendingDeviceKey(key, device []byte) pendingDeviceKey
|
|
|
|
DeviceFromPendingDeviceKey(key []byte) []byte
|
2018-09-18 08:41:06 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
// defaultKeyer implements our key scheme. It needs folder and device
|
|
|
|
// indexes.
|
|
|
|
type defaultKeyer struct {
|
|
|
|
folderIdx *smallIndex
|
|
|
|
deviceIdx *smallIndex
|
|
|
|
}
|
|
|
|
|
|
|
|
func newDefaultKeyer(folderIdx, deviceIdx *smallIndex) defaultKeyer {
|
|
|
|
return defaultKeyer{
|
|
|
|
folderIdx: folderIdx,
|
|
|
|
deviceIdx: deviceIdx,
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
type deviceFileKey []byte
|
|
|
|
|
2018-10-11 10:09:44 +00:00
|
|
|
func (k deviceFileKey) WithoutNameAndDevice() []byte {
|
|
|
|
return k[:keyPrefixLen+keyFolderLen]
|
2018-09-18 08:41:06 +00:00
|
|
|
}
|
|
|
|
|
2020-03-18 16:34:46 +00:00
|
|
|
func (k deviceFileKey) WithoutName() []byte {
|
|
|
|
return k[:keyPrefixLen+keyFolderLen+keyDeviceLen]
|
|
|
|
}
|
|
|
|
|
2019-11-29 08:11:52 +00:00
|
|
|
func (k defaultKeyer) GenerateDeviceFileKey(key, folder, device, name []byte) (deviceFileKey, error) {
|
|
|
|
folderID, err := k.folderIdx.ID(folder)
|
|
|
|
if err != nil {
|
|
|
|
return nil, err
|
|
|
|
}
|
|
|
|
deviceID, err := k.deviceIdx.ID(device)
|
|
|
|
if err != nil {
|
|
|
|
return nil, err
|
|
|
|
}
|
2018-09-18 08:41:06 +00:00
|
|
|
key = resize(key, keyPrefixLen+keyFolderLen+keyDeviceLen+len(name))
|
|
|
|
key[0] = KeyTypeDevice
|
2019-11-29 08:11:52 +00:00
|
|
|
binary.BigEndian.PutUint32(key[keyPrefixLen:], folderID)
|
|
|
|
binary.BigEndian.PutUint32(key[keyPrefixLen+keyFolderLen:], deviceID)
|
2018-09-18 08:41:06 +00:00
|
|
|
copy(key[keyPrefixLen+keyFolderLen+keyDeviceLen:], name)
|
2019-11-29 08:11:52 +00:00
|
|
|
return key, nil
|
2018-09-18 08:41:06 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
func (k defaultKeyer) NameFromDeviceFileKey(key []byte) []byte {
|
|
|
|
return key[keyPrefixLen+keyFolderLen+keyDeviceLen:]
|
|
|
|
}
|
|
|
|
|
|
|
|
func (k defaultKeyer) DeviceFromDeviceFileKey(key []byte) ([]byte, bool) {
|
|
|
|
return k.deviceIdx.Val(binary.BigEndian.Uint32(key[keyPrefixLen+keyFolderLen:]))
|
|
|
|
}
|
|
|
|
|
|
|
|
func (k defaultKeyer) FolderFromDeviceFileKey(key []byte) ([]byte, bool) {
|
|
|
|
return k.folderIdx.Val(binary.BigEndian.Uint32(key[keyPrefixLen:]))
|
|
|
|
}
|
|
|
|
|
|
|
|
type globalVersionKey []byte
|
|
|
|
|
|
|
|
func (k globalVersionKey) WithoutName() []byte {
|
|
|
|
return k[:keyPrefixLen+keyFolderLen]
|
|
|
|
}
|
|
|
|
|
2019-11-29 08:11:52 +00:00
|
|
|
func (k defaultKeyer) GenerateGlobalVersionKey(key, folder, name []byte) (globalVersionKey, error) {
|
|
|
|
folderID, err := k.folderIdx.ID(folder)
|
|
|
|
if err != nil {
|
|
|
|
return nil, err
|
|
|
|
}
|
2018-09-18 08:41:06 +00:00
|
|
|
key = resize(key, keyPrefixLen+keyFolderLen+len(name))
|
|
|
|
key[0] = KeyTypeGlobal
|
2019-11-29 08:11:52 +00:00
|
|
|
binary.BigEndian.PutUint32(key[keyPrefixLen:], folderID)
|
2018-09-18 08:41:06 +00:00
|
|
|
copy(key[keyPrefixLen+keyFolderLen:], name)
|
2019-11-29 08:11:52 +00:00
|
|
|
return key, nil
|
2018-09-18 08:41:06 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
func (k defaultKeyer) NameFromGlobalVersionKey(key []byte) []byte {
|
|
|
|
return key[keyPrefixLen+keyFolderLen:]
|
|
|
|
}
|
|
|
|
|
2019-01-23 09:22:33 +00:00
|
|
|
type blockMapKey []byte
|
|
|
|
|
2019-11-29 08:11:52 +00:00
|
|
|
func (k defaultKeyer) GenerateBlockMapKey(key, folder, hash, name []byte) (blockMapKey, error) {
|
|
|
|
folderID, err := k.folderIdx.ID(folder)
|
|
|
|
if err != nil {
|
|
|
|
return nil, err
|
|
|
|
}
|
2019-01-23 09:22:33 +00:00
|
|
|
key = resize(key, keyPrefixLen+keyFolderLen+keyHashLen+len(name))
|
|
|
|
key[0] = KeyTypeBlock
|
2019-11-29 08:11:52 +00:00
|
|
|
binary.BigEndian.PutUint32(key[keyPrefixLen:], folderID)
|
2019-01-23 09:22:33 +00:00
|
|
|
copy(key[keyPrefixLen+keyFolderLen:], hash)
|
|
|
|
copy(key[keyPrefixLen+keyFolderLen+keyHashLen:], name)
|
2019-11-29 08:11:52 +00:00
|
|
|
return key, nil
|
2019-01-23 09:22:33 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
func (k defaultKeyer) NameFromBlockMapKey(key []byte) []byte {
|
|
|
|
return key[keyPrefixLen+keyFolderLen+keyHashLen:]
|
|
|
|
}
|
|
|
|
|
|
|
|
func (k blockMapKey) WithoutHashAndName() []byte {
|
|
|
|
return k[:keyPrefixLen+keyFolderLen]
|
|
|
|
}
|
|
|
|
|
2020-05-11 18:15:11 +00:00
|
|
|
type blockListMapKey []byte
|
|
|
|
|
|
|
|
func (k defaultKeyer) GenerateBlockListMapKey(key, folder, hash, name []byte) (blockListMapKey, error) {
|
|
|
|
folderID, err := k.folderIdx.ID(folder)
|
|
|
|
if err != nil {
|
|
|
|
return nil, err
|
|
|
|
}
|
|
|
|
key = resize(key, keyPrefixLen+keyFolderLen+keyHashLen+len(name))
|
|
|
|
key[0] = KeyTypeBlockListMap
|
|
|
|
binary.BigEndian.PutUint32(key[keyPrefixLen:], folderID)
|
|
|
|
copy(key[keyPrefixLen+keyFolderLen:], hash)
|
|
|
|
copy(key[keyPrefixLen+keyFolderLen+keyHashLen:], name)
|
|
|
|
return key, nil
|
|
|
|
}
|
|
|
|
|
|
|
|
func (k defaultKeyer) NameFromBlockListMapKey(key []byte) []byte {
|
|
|
|
return key[keyPrefixLen+keyFolderLen+keyHashLen:]
|
|
|
|
}
|
|
|
|
|
|
|
|
func (k blockListMapKey) WithoutHashAndName() []byte {
|
|
|
|
return k[:keyPrefixLen+keyFolderLen]
|
|
|
|
}
|
|
|
|
|
2018-09-18 08:41:06 +00:00
|
|
|
type needFileKey []byte
|
|
|
|
|
|
|
|
func (k needFileKey) WithoutName() []byte {
|
|
|
|
return k[:keyPrefixLen+keyFolderLen]
|
|
|
|
}
|
|
|
|
|
2019-11-29 08:11:52 +00:00
|
|
|
func (k defaultKeyer) GenerateNeedFileKey(key, folder, name []byte) (needFileKey, error) {
|
|
|
|
folderID, err := k.folderIdx.ID(folder)
|
|
|
|
if err != nil {
|
|
|
|
return nil, err
|
|
|
|
}
|
2018-09-18 08:41:06 +00:00
|
|
|
key = resize(key, keyPrefixLen+keyFolderLen+len(name))
|
|
|
|
key[0] = KeyTypeNeed
|
2019-11-29 08:11:52 +00:00
|
|
|
binary.BigEndian.PutUint32(key[keyPrefixLen:], folderID)
|
2018-09-18 08:41:06 +00:00
|
|
|
copy(key[keyPrefixLen+keyFolderLen:], name)
|
2019-11-29 08:11:52 +00:00
|
|
|
return key, nil
|
2018-09-18 08:41:06 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
type sequenceKey []byte
|
|
|
|
|
|
|
|
func (k sequenceKey) WithoutSequence() []byte {
|
|
|
|
return k[:keyPrefixLen+keyFolderLen]
|
|
|
|
}
|
|
|
|
|
2019-11-29 08:11:52 +00:00
|
|
|
func (k defaultKeyer) GenerateSequenceKey(key, folder []byte, seq int64) (sequenceKey, error) {
|
|
|
|
folderID, err := k.folderIdx.ID(folder)
|
|
|
|
if err != nil {
|
|
|
|
return nil, err
|
|
|
|
}
|
2018-09-18 08:41:06 +00:00
|
|
|
key = resize(key, keyPrefixLen+keyFolderLen+keySequenceLen)
|
|
|
|
key[0] = KeyTypeSequence
|
2019-11-29 08:11:52 +00:00
|
|
|
binary.BigEndian.PutUint32(key[keyPrefixLen:], folderID)
|
2018-09-18 08:41:06 +00:00
|
|
|
binary.BigEndian.PutUint64(key[keyPrefixLen+keyFolderLen:], uint64(seq))
|
2019-11-29 08:11:52 +00:00
|
|
|
return key, nil
|
2018-09-18 08:41:06 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
func (k defaultKeyer) SequenceFromSequenceKey(key []byte) int64 {
|
|
|
|
return int64(binary.BigEndian.Uint64(key[keyPrefixLen+keyFolderLen:]))
|
|
|
|
}
|
|
|
|
|
|
|
|
type indexIDKey []byte
|
|
|
|
|
2019-11-29 08:11:52 +00:00
|
|
|
func (k defaultKeyer) GenerateIndexIDKey(key, device, folder []byte) (indexIDKey, error) {
|
|
|
|
deviceID, err := k.deviceIdx.ID(device)
|
|
|
|
if err != nil {
|
|
|
|
return nil, err
|
|
|
|
}
|
|
|
|
folderID, err := k.folderIdx.ID(folder)
|
|
|
|
if err != nil {
|
|
|
|
return nil, err
|
|
|
|
}
|
2018-09-18 08:41:06 +00:00
|
|
|
key = resize(key, keyPrefixLen+keyDeviceLen+keyFolderLen)
|
|
|
|
key[0] = KeyTypeIndexID
|
2019-11-29 08:11:52 +00:00
|
|
|
binary.BigEndian.PutUint32(key[keyPrefixLen:], deviceID)
|
|
|
|
binary.BigEndian.PutUint32(key[keyPrefixLen+keyDeviceLen:], folderID)
|
|
|
|
return key, nil
|
2018-09-18 08:41:06 +00:00
|
|
|
}
|
|
|
|
|
2020-12-21 10:10:59 +00:00
|
|
|
func (k defaultKeyer) FolderFromIndexIDKey(key []byte) ([]byte, bool) {
|
|
|
|
return k.folderIdx.Val(binary.BigEndian.Uint32(key[keyPrefixLen+keyDeviceLen:]))
|
|
|
|
}
|
|
|
|
|
2018-09-18 08:41:06 +00:00
|
|
|
type mtimesKey []byte
|
|
|
|
|
2019-11-29 08:11:52 +00:00
|
|
|
func (k defaultKeyer) GenerateMtimesKey(key, folder []byte) (mtimesKey, error) {
|
|
|
|
folderID, err := k.folderIdx.ID(folder)
|
|
|
|
if err != nil {
|
|
|
|
return nil, err
|
|
|
|
}
|
2018-09-18 08:41:06 +00:00
|
|
|
key = resize(key, keyPrefixLen+keyFolderLen)
|
|
|
|
key[0] = KeyTypeVirtualMtime
|
2019-11-29 08:11:52 +00:00
|
|
|
binary.BigEndian.PutUint32(key[keyPrefixLen:], folderID)
|
|
|
|
return key, nil
|
2018-09-18 08:41:06 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
type folderMetaKey []byte
|
|
|
|
|
2019-11-29 08:11:52 +00:00
|
|
|
func (k defaultKeyer) GenerateFolderMetaKey(key, folder []byte) (folderMetaKey, error) {
|
|
|
|
folderID, err := k.folderIdx.ID(folder)
|
|
|
|
if err != nil {
|
|
|
|
return nil, err
|
|
|
|
}
|
2018-09-18 08:41:06 +00:00
|
|
|
key = resize(key, keyPrefixLen+keyFolderLen)
|
|
|
|
key[0] = KeyTypeFolderMeta
|
2019-11-29 08:11:52 +00:00
|
|
|
binary.BigEndian.PutUint32(key[keyPrefixLen:], folderID)
|
|
|
|
return key, nil
|
2018-09-18 08:41:06 +00:00
|
|
|
}
|
|
|
|
|
lib/db: Deduplicate block lists in database (fixes #5898) (#6283)
* lib/db: Deduplicate block lists in database (fixes #5898)
This moves the block list in the database out from being just a field on
the FileInfo to being an object of its own. When putting a FileInfo we
marshal the block list separately and store it keyed by the sha256 of
the marshalled block list. When getting, if we are not doing a
"truncated" get, we do an extra read and unmarshal for the block list.
Old block lists are cleared out by a periodic GC sweep. The alternative
would be to use refcounting, but:
- There is a larger risk of getting that wrong and either dropping a
block list in error or keeping them around forever.
- It's tricky with our current database, as we don't have dirty reads.
This means that if we update two FileInfos with identical block lists in
the same transaction we can't just do read/modify/write for the ref
counters as we wouldn't see our own first update. See above about
tracking this and risks about getting it wrong.
GC uses a bloom filter for keys to avoid heavy RAM usage. GC can't run
concurrently with FileInfo updates so there is a new lock around those
operation at the lowlevel.
The end result is a much more compact database, especially for setups
with many peers where files get duplicated many times.
This is per-key-class stats for a large database I'm currently working
with, under the current schema:
```
0x00: 9138161 items, 870876 KB keys + 7397482 KB data, 95 B + 809 B avg, 1637651 B max
0x01: 185656 items, 10388 KB keys + 1790909 KB data, 55 B + 9646 B avg, 924525 B max
0x02: 916890 items, 84795 KB keys + 3667 KB data, 92 B + 4 B avg, 192 B max
0x03: 384 items, 27 KB keys + 5 KB data, 72 B + 15 B avg, 87 B max
0x04: 1109 items, 17 KB keys + 17 KB data, 15 B + 15 B avg, 69 B max
0x06: 383 items, 3 KB keys + 0 KB data, 9 B + 2 B avg, 18 B max
0x07: 510 items, 4 KB keys + 12 KB data, 9 B + 24 B avg, 41 B max
0x08: 1349 items, 12 KB keys + 10 KB data, 9 B + 8 B avg, 17 B max
0x09: 194 items, 0 KB keys + 123 KB data, 5 B + 634 B avg, 11484 B max
0x0a: 3 items, 0 KB keys + 0 KB data, 14 B + 7 B avg, 30 B max
0x0b: 181836 items, 2363 KB keys + 10694 KB data, 13 B + 58 B avg, 173 B max
Total 10426475 items, 968490 KB keys + 9202925 KB data.
```
Note 7.4 GB of data in class 00, total size 9.2 GB. After running the
migration we get this instead:
```
0x00: 9138161 items, 870876 KB keys + 2611392 KB data, 95 B + 285 B avg, 4788 B max
0x01: 185656 items, 10388 KB keys + 1790909 KB data, 55 B + 9646 B avg, 924525 B max
0x02: 916890 items, 84795 KB keys + 3667 KB data, 92 B + 4 B avg, 192 B max
0x03: 384 items, 27 KB keys + 5 KB data, 72 B + 15 B avg, 87 B max
0x04: 1109 items, 17 KB keys + 17 KB data, 15 B + 15 B avg, 69 B max
0x06: 383 items, 3 KB keys + 0 KB data, 9 B + 2 B avg, 18 B max
0x07: 510 items, 4 KB keys + 12 KB data, 9 B + 24 B avg, 41 B max
0x09: 194 items, 0 KB keys + 123 KB data, 5 B + 634 B avg, 11484 B max
0x0a: 3 items, 0 KB keys + 0 KB data, 14 B + 17 B avg, 51 B max
0x0b: 181836 items, 2363 KB keys + 10694 KB data, 13 B + 58 B avg, 173 B max
0x0d: 44282 items, 1461 KB keys + 61081 KB data, 33 B + 1379 B avg, 1637399 B max
Total 10469408 items, 969939 KB keys + 4477905 KB data.
```
Class 00 is now down to 2.6 GB, with just 61 MB added in class 0d.
There will be some additional reads in some cases which theoretically
hurts performance, but this will be more than compensated for by smaller
writes and better compaction.
On my own home setup which just has three devices and a handful of
folders the difference is smaller in absolute numbers of course, but
still less than half the old size:
```
0x00: 297122 items, 20894 KB keys + 306860 KB data, 70 B + 1032 B avg, 103237 B max
0x01: 115299 items, 7738 KB keys + 17542 KB data, 67 B + 152 B avg, 419 B max
0x02: 1430537 items, 121223 KB keys + 5722 KB data, 84 B + 4 B avg, 253 B max
...
Total 1947412 items, 151268 KB keys + 337485 KB data.
```
to:
```
0x00: 297122 items, 20894 KB keys + 37038 KB data, 70 B + 124 B avg, 520 B max
0x01: 115299 items, 7738 KB keys + 17542 KB data, 67 B + 152 B avg, 419 B max
0x02: 1430537 items, 121223 KB keys + 5722 KB data, 84 B + 4 B avg, 253 B max
...
0x0d: 18041 items, 595 KB keys + 71964 KB data, 33 B + 3988 B avg, 101109 B max
Total 1965447 items, 151863 KB keys + 139628 KB data.
```
* wip
* wip
* wip
* wip
2020-01-24 07:35:44 +00:00
|
|
|
type blockListKey []byte
|
|
|
|
|
|
|
|
func (k defaultKeyer) GenerateBlockListKey(key []byte, hash []byte) blockListKey {
|
|
|
|
key = resize(key, keyPrefixLen+len(hash))
|
|
|
|
key[0] = KeyTypeBlockList
|
|
|
|
copy(key[keyPrefixLen:], hash)
|
|
|
|
return key
|
|
|
|
}
|
|
|
|
|
2020-05-13 12:28:42 +00:00
|
|
|
func (k blockListKey) Hash() []byte {
|
|
|
|
return k[keyPrefixLen:]
|
|
|
|
}
|
|
|
|
|
|
|
|
type versionKey []byte
|
|
|
|
|
|
|
|
func (k defaultKeyer) GenerateVersionKey(key []byte, hash []byte) versionKey {
|
|
|
|
key = resize(key, keyPrefixLen+len(hash))
|
|
|
|
key[0] = KeyTypeVersion
|
|
|
|
copy(key[keyPrefixLen:], hash)
|
|
|
|
return key
|
|
|
|
}
|
|
|
|
|
|
|
|
func (k versionKey) Hash() []byte {
|
lib/db: Deduplicate block lists in database (fixes #5898) (#6283)
* lib/db: Deduplicate block lists in database (fixes #5898)
This moves the block list in the database out from being just a field on
the FileInfo to being an object of its own. When putting a FileInfo we
marshal the block list separately and store it keyed by the sha256 of
the marshalled block list. When getting, if we are not doing a
"truncated" get, we do an extra read and unmarshal for the block list.
Old block lists are cleared out by a periodic GC sweep. The alternative
would be to use refcounting, but:
- There is a larger risk of getting that wrong and either dropping a
block list in error or keeping them around forever.
- It's tricky with our current database, as we don't have dirty reads.
This means that if we update two FileInfos with identical block lists in
the same transaction we can't just do read/modify/write for the ref
counters as we wouldn't see our own first update. See above about
tracking this and risks about getting it wrong.
GC uses a bloom filter for keys to avoid heavy RAM usage. GC can't run
concurrently with FileInfo updates so there is a new lock around those
operation at the lowlevel.
The end result is a much more compact database, especially for setups
with many peers where files get duplicated many times.
This is per-key-class stats for a large database I'm currently working
with, under the current schema:
```
0x00: 9138161 items, 870876 KB keys + 7397482 KB data, 95 B + 809 B avg, 1637651 B max
0x01: 185656 items, 10388 KB keys + 1790909 KB data, 55 B + 9646 B avg, 924525 B max
0x02: 916890 items, 84795 KB keys + 3667 KB data, 92 B + 4 B avg, 192 B max
0x03: 384 items, 27 KB keys + 5 KB data, 72 B + 15 B avg, 87 B max
0x04: 1109 items, 17 KB keys + 17 KB data, 15 B + 15 B avg, 69 B max
0x06: 383 items, 3 KB keys + 0 KB data, 9 B + 2 B avg, 18 B max
0x07: 510 items, 4 KB keys + 12 KB data, 9 B + 24 B avg, 41 B max
0x08: 1349 items, 12 KB keys + 10 KB data, 9 B + 8 B avg, 17 B max
0x09: 194 items, 0 KB keys + 123 KB data, 5 B + 634 B avg, 11484 B max
0x0a: 3 items, 0 KB keys + 0 KB data, 14 B + 7 B avg, 30 B max
0x0b: 181836 items, 2363 KB keys + 10694 KB data, 13 B + 58 B avg, 173 B max
Total 10426475 items, 968490 KB keys + 9202925 KB data.
```
Note 7.4 GB of data in class 00, total size 9.2 GB. After running the
migration we get this instead:
```
0x00: 9138161 items, 870876 KB keys + 2611392 KB data, 95 B + 285 B avg, 4788 B max
0x01: 185656 items, 10388 KB keys + 1790909 KB data, 55 B + 9646 B avg, 924525 B max
0x02: 916890 items, 84795 KB keys + 3667 KB data, 92 B + 4 B avg, 192 B max
0x03: 384 items, 27 KB keys + 5 KB data, 72 B + 15 B avg, 87 B max
0x04: 1109 items, 17 KB keys + 17 KB data, 15 B + 15 B avg, 69 B max
0x06: 383 items, 3 KB keys + 0 KB data, 9 B + 2 B avg, 18 B max
0x07: 510 items, 4 KB keys + 12 KB data, 9 B + 24 B avg, 41 B max
0x09: 194 items, 0 KB keys + 123 KB data, 5 B + 634 B avg, 11484 B max
0x0a: 3 items, 0 KB keys + 0 KB data, 14 B + 17 B avg, 51 B max
0x0b: 181836 items, 2363 KB keys + 10694 KB data, 13 B + 58 B avg, 173 B max
0x0d: 44282 items, 1461 KB keys + 61081 KB data, 33 B + 1379 B avg, 1637399 B max
Total 10469408 items, 969939 KB keys + 4477905 KB data.
```
Class 00 is now down to 2.6 GB, with just 61 MB added in class 0d.
There will be some additional reads in some cases which theoretically
hurts performance, but this will be more than compensated for by smaller
writes and better compaction.
On my own home setup which just has three devices and a handful of
folders the difference is smaller in absolute numbers of course, but
still less than half the old size:
```
0x00: 297122 items, 20894 KB keys + 306860 KB data, 70 B + 1032 B avg, 103237 B max
0x01: 115299 items, 7738 KB keys + 17542 KB data, 67 B + 152 B avg, 419 B max
0x02: 1430537 items, 121223 KB keys + 5722 KB data, 84 B + 4 B avg, 253 B max
...
Total 1947412 items, 151268 KB keys + 337485 KB data.
```
to:
```
0x00: 297122 items, 20894 KB keys + 37038 KB data, 70 B + 124 B avg, 520 B max
0x01: 115299 items, 7738 KB keys + 17542 KB data, 67 B + 152 B avg, 419 B max
0x02: 1430537 items, 121223 KB keys + 5722 KB data, 84 B + 4 B avg, 253 B max
...
0x0d: 18041 items, 595 KB keys + 71964 KB data, 33 B + 3988 B avg, 101109 B max
Total 1965447 items, 151863 KB keys + 139628 KB data.
```
* wip
* wip
* wip
* wip
2020-01-24 07:35:44 +00:00
|
|
|
return k[keyPrefixLen:]
|
|
|
|
}
|
|
|
|
|
2020-12-17 18:54:31 +00:00
|
|
|
type pendingFolderKey []byte
|
|
|
|
|
|
|
|
func (k defaultKeyer) GeneratePendingFolderKey(key, device, folder []byte) (pendingFolderKey, error) {
|
|
|
|
deviceID, err := k.deviceIdx.ID(device)
|
|
|
|
if err != nil {
|
|
|
|
return nil, err
|
|
|
|
}
|
|
|
|
key = resize(key, keyPrefixLen+keyDeviceLen+len(folder))
|
|
|
|
key[0] = KeyTypePendingFolder
|
|
|
|
binary.BigEndian.PutUint32(key[keyPrefixLen:], deviceID)
|
|
|
|
copy(key[keyPrefixLen+keyDeviceLen:], folder)
|
|
|
|
return key, nil
|
|
|
|
}
|
|
|
|
|
|
|
|
func (k defaultKeyer) FolderFromPendingFolderKey(key []byte) []byte {
|
|
|
|
return key[keyPrefixLen+keyDeviceLen:]
|
|
|
|
}
|
|
|
|
|
|
|
|
func (k defaultKeyer) DeviceFromPendingFolderKey(key []byte) ([]byte, bool) {
|
|
|
|
return k.deviceIdx.Val(binary.BigEndian.Uint32(key[keyPrefixLen:]))
|
|
|
|
}
|
|
|
|
|
|
|
|
type pendingDeviceKey []byte
|
|
|
|
|
|
|
|
func (k defaultKeyer) GeneratePendingDeviceKey(key, device []byte) pendingDeviceKey {
|
|
|
|
key = resize(key, keyPrefixLen+len(device))
|
|
|
|
key[0] = KeyTypePendingDevice
|
|
|
|
copy(key[keyPrefixLen:], device)
|
|
|
|
return key
|
|
|
|
}
|
|
|
|
|
|
|
|
func (k defaultKeyer) DeviceFromPendingDeviceKey(key []byte) []byte {
|
|
|
|
return key[keyPrefixLen:]
|
|
|
|
}
|
|
|
|
|
2018-09-18 08:41:06 +00:00
|
|
|
// resize returns a byte slice of the specified size, reusing bs if possible
|
|
|
|
func resize(bs []byte, size int) []byte {
|
|
|
|
if cap(bs) < size {
|
|
|
|
return make([]byte, size)
|
|
|
|
}
|
|
|
|
return bs[:size]
|
|
|
|
}
|