2015-10-29 00:07:51 -07:00
|
|
|
// Copyright (C) 2014 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,
|
2017-02-08 23:52:18 -07:00
|
|
|
// You can obtain one at https://mozilla.org/MPL/2.0/.
|
2015-10-29 00:07:51 -07:00
|
|
|
|
|
|
|
package db
|
|
|
|
|
|
|
|
import (
|
2020-01-21 10:23:08 -07:00
|
|
|
"bytes"
|
2020-03-19 06:32:22 -07:00
|
|
|
"errors"
|
2020-05-11 11:15:11 -07:00
|
|
|
"github.com/syncthing/syncthing/lib/osutil"
|
2020-01-21 10:23:08 -07:00
|
|
|
|
2019-11-29 01:11:52 -07:00
|
|
|
"github.com/syncthing/syncthing/lib/db/backend"
|
2015-10-29 00:07:51 -07:00
|
|
|
"github.com/syncthing/syncthing/lib/protocol"
|
|
|
|
)
|
|
|
|
|
2020-05-30 00:50:23 -07:00
|
|
|
var (
|
|
|
|
errEntryFromGlobalMissing = errors.New("device present in global list but missing as device/fileinfo entry")
|
|
|
|
errEmptyGlobal = errors.New("no versions in global list")
|
|
|
|
errEmptyFileVersion = errors.New("no devices in global file version")
|
|
|
|
)
|
2020-03-16 00:45:45 -07:00
|
|
|
|
2015-10-29 00:07:51 -07:00
|
|
|
// A readOnlyTransaction represents a database snapshot.
|
|
|
|
type readOnlyTransaction struct {
|
2019-11-29 01:11:52 -07:00
|
|
|
backend.ReadTransaction
|
2019-02-14 16:15:13 -07:00
|
|
|
keyer keyer
|
2015-10-29 00:07:51 -07:00
|
|
|
}
|
|
|
|
|
2019-12-02 00:18:04 -07:00
|
|
|
func (db *Lowlevel) newReadOnlyTransaction() (readOnlyTransaction, error) {
|
2019-11-29 01:11:52 -07:00
|
|
|
tran, err := db.NewReadTransaction()
|
|
|
|
if err != nil {
|
|
|
|
return readOnlyTransaction{}, err
|
2015-10-29 00:07:51 -07:00
|
|
|
}
|
2019-11-29 01:11:52 -07:00
|
|
|
return readOnlyTransaction{
|
|
|
|
ReadTransaction: tran,
|
|
|
|
keyer: db.keyer,
|
|
|
|
}, nil
|
2015-10-29 00:07:51 -07:00
|
|
|
}
|
|
|
|
|
|
|
|
func (t readOnlyTransaction) close() {
|
|
|
|
t.Release()
|
|
|
|
}
|
|
|
|
|
2019-11-29 01:11:52 -07:00
|
|
|
func (t readOnlyTransaction) getFile(folder, device, file []byte) (protocol.FileInfo, bool, error) {
|
|
|
|
key, err := t.keyer.GenerateDeviceFileKey(nil, folder, device, file)
|
|
|
|
if err != nil {
|
|
|
|
return protocol.FileInfo{}, false, err
|
|
|
|
}
|
|
|
|
return t.getFileByKey(key)
|
2019-01-18 03:34:18 -07:00
|
|
|
}
|
|
|
|
|
2019-11-29 01:11:52 -07:00
|
|
|
func (t readOnlyTransaction) getFileByKey(key []byte) (protocol.FileInfo, bool, error) {
|
|
|
|
f, ok, err := t.getFileTrunc(key, false)
|
|
|
|
if err != nil || !ok {
|
|
|
|
return protocol.FileInfo{}, false, err
|
2019-01-18 03:34:18 -07:00
|
|
|
}
|
2019-11-29 01:11:52 -07:00
|
|
|
return f.(protocol.FileInfo), true, nil
|
2019-01-18 03:34:18 -07:00
|
|
|
}
|
|
|
|
|
2020-05-30 00:50:23 -07:00
|
|
|
func (t readOnlyTransaction) getFileTrunc(key []byte, trunc bool) (protocol.FileIntf, bool, error) {
|
2019-11-29 01:11:52 -07:00
|
|
|
bs, err := t.Get(key)
|
|
|
|
if backend.IsNotFound(err) {
|
|
|
|
return nil, false, nil
|
2019-01-18 03:34:18 -07:00
|
|
|
}
|
|
|
|
if err != nil {
|
2019-11-29 01:11:52 -07:00
|
|
|
return nil, false, err
|
2019-01-18 03:34:18 -07: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 00:35:44 -07:00
|
|
|
f, err := t.unmarshalTrunc(bs, trunc)
|
2020-02-11 07:37:22 -07:00
|
|
|
if backend.IsNotFound(err) {
|
|
|
|
return nil, false, nil
|
|
|
|
}
|
2019-01-18 03:34:18 -07:00
|
|
|
if err != nil {
|
2019-11-29 01:11:52 -07:00
|
|
|
return nil, false, err
|
2019-01-18 03:34:18 -07:00
|
|
|
}
|
2019-11-29 01:11:52 -07:00
|
|
|
return f, true, nil
|
2015-10-29 00:07:51 -07:00
|
|
|
}
|
|
|
|
|
2020-05-30 00:50:23 -07:00
|
|
|
func (t readOnlyTransaction) unmarshalTrunc(bs []byte, trunc bool) (protocol.FileIntf, 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 00:35:44 -07:00
|
|
|
if trunc {
|
|
|
|
var tf FileInfoTruncated
|
|
|
|
err := tf.Unmarshal(bs)
|
|
|
|
if err != nil {
|
|
|
|
return nil, err
|
|
|
|
}
|
2020-05-13 05:28:42 -07:00
|
|
|
if err := t.fillTruncated(&tf); err != nil {
|
|
|
|
return nil, err
|
|
|
|
}
|
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 00:35:44 -07:00
|
|
|
return tf, nil
|
|
|
|
}
|
|
|
|
|
2020-02-27 03:19:21 -07:00
|
|
|
var fi protocol.FileInfo
|
|
|
|
if err := fi.Unmarshal(bs); err != nil {
|
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 00:35:44 -07:00
|
|
|
return nil, err
|
|
|
|
}
|
2020-02-27 03:19:21 -07:00
|
|
|
if err := t.fillFileInfo(&fi); err != nil {
|
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 00:35:44 -07:00
|
|
|
return nil, err
|
|
|
|
}
|
2020-02-27 03:19:21 -07:00
|
|
|
return fi, nil
|
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 00:35:44 -07:00
|
|
|
}
|
|
|
|
|
2020-05-13 05:28:42 -07:00
|
|
|
// fillFileInfo follows the (possible) indirection of blocks and version
|
|
|
|
// vector and fills it out.
|
2020-02-27 03:19:21 -07:00
|
|
|
func (t readOnlyTransaction) fillFileInfo(fi *protocol.FileInfo) error {
|
|
|
|
var key []byte
|
|
|
|
|
|
|
|
if len(fi.Blocks) == 0 && len(fi.BlocksHash) != 0 {
|
|
|
|
// The blocks list is indirected and we need to load it.
|
|
|
|
key = t.keyer.GenerateBlockListKey(key, fi.BlocksHash)
|
|
|
|
bs, err := t.Get(key)
|
|
|
|
if err != nil {
|
|
|
|
return err
|
|
|
|
}
|
|
|
|
var bl BlockList
|
|
|
|
if err := bl.Unmarshal(bs); err != nil {
|
|
|
|
return err
|
|
|
|
}
|
|
|
|
fi.Blocks = bl.Blocks
|
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 00:35:44 -07:00
|
|
|
}
|
2020-02-27 03:19:21 -07:00
|
|
|
|
2020-05-13 05:28:42 -07:00
|
|
|
if len(fi.VersionHash) != 0 {
|
|
|
|
key = t.keyer.GenerateVersionKey(key, fi.VersionHash)
|
|
|
|
bs, err := t.Get(key)
|
|
|
|
if err != nil {
|
|
|
|
return err
|
|
|
|
}
|
|
|
|
var v protocol.Vector
|
|
|
|
if err := v.Unmarshal(bs); err != nil {
|
|
|
|
return err
|
|
|
|
}
|
|
|
|
fi.Version = v
|
|
|
|
}
|
|
|
|
|
|
|
|
return nil
|
|
|
|
}
|
|
|
|
|
|
|
|
// fillTruncated follows the (possible) indirection of version vector and
|
|
|
|
// fills it.
|
|
|
|
func (t readOnlyTransaction) fillTruncated(fi *FileInfoTruncated) error {
|
|
|
|
var key []byte
|
|
|
|
|
|
|
|
if len(fi.VersionHash) == 0 {
|
|
|
|
return nil
|
|
|
|
}
|
|
|
|
|
|
|
|
key = t.keyer.GenerateVersionKey(key, fi.VersionHash)
|
|
|
|
bs, err := t.Get(key)
|
|
|
|
if err != nil {
|
|
|
|
return err
|
|
|
|
}
|
|
|
|
var v protocol.Vector
|
|
|
|
if err := v.Unmarshal(bs); err != nil {
|
|
|
|
return err
|
|
|
|
}
|
|
|
|
fi.Version = v
|
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 00:35:44 -07:00
|
|
|
return nil
|
|
|
|
}
|
|
|
|
|
2020-05-01 00:30:20 -07:00
|
|
|
func (t readOnlyTransaction) getGlobalVersions(keyBuf, folder, file []byte) (VersionList, error) {
|
2019-11-29 01:11:52 -07:00
|
|
|
var err error
|
|
|
|
keyBuf, err = t.keyer.GenerateGlobalVersionKey(keyBuf, folder, file)
|
|
|
|
if err != nil {
|
2020-05-01 00:30:20 -07:00
|
|
|
return VersionList{}, err
|
2019-11-29 01:11:52 -07:00
|
|
|
}
|
2020-05-01 00:30:20 -07:00
|
|
|
return t.getGlobalVersionsByKey(keyBuf)
|
|
|
|
}
|
2019-01-18 05:01:39 -07:00
|
|
|
|
2020-05-01 00:30:20 -07:00
|
|
|
func (t readOnlyTransaction) getGlobalVersionsByKey(key []byte) (VersionList, error) {
|
|
|
|
bs, err := t.Get(key)
|
2019-01-18 05:01:39 -07:00
|
|
|
if err != nil {
|
2020-05-01 00:30:20 -07:00
|
|
|
return VersionList{}, err
|
2019-01-18 05:01:39 -07:00
|
|
|
}
|
|
|
|
|
2020-03-16 02:09:27 -07:00
|
|
|
var vl VersionList
|
|
|
|
if err := vl.Unmarshal(bs); err != nil {
|
2020-05-01 00:30:20 -07:00
|
|
|
return VersionList{}, err
|
|
|
|
}
|
|
|
|
|
|
|
|
return vl, nil
|
|
|
|
}
|
|
|
|
|
2020-05-30 00:50:23 -07:00
|
|
|
func (t readOnlyTransaction) getGlobal(keyBuf, folder, file []byte, truncate bool) ([]byte, protocol.FileIntf, bool, error) {
|
2020-05-01 00:30:20 -07:00
|
|
|
vl, err := t.getGlobalVersions(keyBuf, folder, file)
|
|
|
|
if backend.IsNotFound(err) {
|
|
|
|
return keyBuf, nil, false, nil
|
|
|
|
} else if err != nil {
|
2020-03-16 02:09:27 -07:00
|
|
|
return nil, nil, false, err
|
2019-01-18 05:01:39 -07:00
|
|
|
}
|
2020-05-30 00:50:23 -07:00
|
|
|
var fi protocol.FileIntf
|
|
|
|
keyBuf, fi, _, err = t.getGlobalFromVersionList(keyBuf, folder, file, truncate, vl)
|
|
|
|
return keyBuf, fi, true, err
|
|
|
|
}
|
|
|
|
|
|
|
|
func (t readOnlyTransaction) getGlobalFromVersionList(keyBuf, folder, file []byte, truncate bool, vl VersionList) ([]byte, protocol.FileIntf, FileVersion, error) {
|
|
|
|
fv, ok := vl.GetGlobal()
|
|
|
|
if !ok {
|
|
|
|
return keyBuf, nil, FileVersion{}, errEmptyGlobal
|
2020-05-11 06:07:06 -07:00
|
|
|
}
|
2020-05-30 00:50:23 -07:00
|
|
|
keyBuf, fi, err := t.getGlobalFromFileVersion(keyBuf, folder, file, truncate, fv)
|
|
|
|
return keyBuf, fi, fv, err
|
|
|
|
}
|
2019-01-18 05:01:39 -07:00
|
|
|
|
2020-05-30 00:50:23 -07:00
|
|
|
func (t readOnlyTransaction) getGlobalFromFileVersion(keyBuf, folder, file []byte, truncate bool, fv FileVersion) ([]byte, protocol.FileIntf, error) {
|
|
|
|
dev, ok := fv.FirstDevice()
|
|
|
|
if !ok {
|
|
|
|
return keyBuf, nil, errEmptyFileVersion
|
|
|
|
}
|
|
|
|
keyBuf, err := t.keyer.GenerateDeviceFileKey(keyBuf, folder, dev, file)
|
2019-11-29 01:11:52 -07:00
|
|
|
if err != nil {
|
2020-05-30 00:50:23 -07:00
|
|
|
return keyBuf, nil, err
|
2019-01-18 05:01:39 -07:00
|
|
|
}
|
2019-11-29 01:11:52 -07:00
|
|
|
fi, ok, err := t.getFileTrunc(keyBuf, truncate)
|
2020-05-30 00:50:23 -07:00
|
|
|
if err != nil {
|
|
|
|
return keyBuf, nil, err
|
2019-11-29 01:11:52 -07:00
|
|
|
}
|
2020-05-30 00:50:23 -07:00
|
|
|
if !ok {
|
|
|
|
return keyBuf, nil, errEntryFromGlobalMissing
|
|
|
|
}
|
|
|
|
return keyBuf, fi, nil
|
2019-01-18 05:01:39 -07:00
|
|
|
}
|
|
|
|
|
2020-01-21 10:23:08 -07:00
|
|
|
func (t *readOnlyTransaction) withHave(folder, device, prefix []byte, truncate bool, fn Iterator) error {
|
|
|
|
if len(prefix) > 0 {
|
|
|
|
unslashedPrefix := prefix
|
|
|
|
if bytes.HasSuffix(prefix, []byte{'/'}) {
|
|
|
|
unslashedPrefix = unslashedPrefix[:len(unslashedPrefix)-1]
|
|
|
|
} else {
|
|
|
|
prefix = append(prefix, '/')
|
|
|
|
}
|
|
|
|
|
|
|
|
key, err := t.keyer.GenerateDeviceFileKey(nil, folder, device, unslashedPrefix)
|
|
|
|
if err != nil {
|
|
|
|
return err
|
|
|
|
}
|
2020-05-08 12:31:43 -07:00
|
|
|
if f, ok, err := t.getFileTrunc(key, truncate); err != nil {
|
2020-01-21 10:23:08 -07:00
|
|
|
return err
|
|
|
|
} else if ok && !fn(f) {
|
|
|
|
return nil
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
key, err := t.keyer.GenerateDeviceFileKey(nil, folder, device, prefix)
|
|
|
|
if err != nil {
|
|
|
|
return err
|
|
|
|
}
|
|
|
|
dbi, err := t.NewPrefixIterator(key)
|
|
|
|
if err != nil {
|
|
|
|
return err
|
|
|
|
}
|
|
|
|
defer dbi.Release()
|
|
|
|
|
|
|
|
for dbi.Next() {
|
|
|
|
name := t.keyer.NameFromDeviceFileKey(dbi.Key())
|
|
|
|
if len(prefix) > 0 && !bytes.HasPrefix(name, prefix) {
|
|
|
|
return nil
|
|
|
|
}
|
|
|
|
|
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 00:35:44 -07:00
|
|
|
f, err := t.unmarshalTrunc(dbi.Value(), truncate)
|
2020-01-21 10:23:08 -07:00
|
|
|
if err != nil {
|
|
|
|
l.Debugln("unmarshal error:", err)
|
|
|
|
continue
|
|
|
|
}
|
|
|
|
if !fn(f) {
|
|
|
|
return nil
|
|
|
|
}
|
|
|
|
}
|
|
|
|
return dbi.Error()
|
|
|
|
}
|
|
|
|
|
|
|
|
func (t *readOnlyTransaction) withHaveSequence(folder []byte, startSeq int64, fn Iterator) error {
|
|
|
|
first, err := t.keyer.GenerateSequenceKey(nil, folder, startSeq)
|
|
|
|
if err != nil {
|
|
|
|
return err
|
|
|
|
}
|
|
|
|
last, err := t.keyer.GenerateSequenceKey(nil, folder, maxInt64)
|
|
|
|
if err != nil {
|
|
|
|
return err
|
|
|
|
}
|
|
|
|
dbi, err := t.NewRangeIterator(first, last)
|
|
|
|
if err != nil {
|
|
|
|
return err
|
|
|
|
}
|
|
|
|
defer dbi.Release()
|
|
|
|
|
|
|
|
for dbi.Next() {
|
|
|
|
f, ok, err := t.getFileByKey(dbi.Value())
|
|
|
|
if err != nil {
|
|
|
|
return err
|
|
|
|
}
|
|
|
|
if !ok {
|
|
|
|
l.Debugln("missing file for sequence number", t.keyer.SequenceFromSequenceKey(dbi.Key()))
|
|
|
|
continue
|
|
|
|
}
|
|
|
|
|
|
|
|
if shouldDebug() {
|
|
|
|
if seq := t.keyer.SequenceFromSequenceKey(dbi.Key()); f.Sequence != seq {
|
2020-05-18 01:42:51 -07:00
|
|
|
l.Debugf("Sequence index corruption (folder %v, file %v): sequence %d != expected %d", string(folder), f.Name, f.Sequence, seq)
|
2020-01-21 10:23:08 -07:00
|
|
|
}
|
|
|
|
}
|
|
|
|
if !fn(f) {
|
|
|
|
return nil
|
|
|
|
}
|
|
|
|
}
|
|
|
|
return dbi.Error()
|
|
|
|
}
|
|
|
|
|
|
|
|
func (t *readOnlyTransaction) withGlobal(folder, prefix []byte, truncate bool, fn Iterator) error {
|
|
|
|
if len(prefix) > 0 {
|
|
|
|
unslashedPrefix := prefix
|
|
|
|
if bytes.HasSuffix(prefix, []byte{'/'}) {
|
|
|
|
unslashedPrefix = unslashedPrefix[:len(unslashedPrefix)-1]
|
|
|
|
} else {
|
|
|
|
prefix = append(prefix, '/')
|
|
|
|
}
|
|
|
|
|
|
|
|
if _, f, ok, err := t.getGlobal(nil, folder, unslashedPrefix, truncate); err != nil {
|
|
|
|
return err
|
|
|
|
} else if ok && !fn(f) {
|
|
|
|
return nil
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
key, err := t.keyer.GenerateGlobalVersionKey(nil, folder, prefix)
|
|
|
|
if err != nil {
|
|
|
|
return err
|
|
|
|
}
|
|
|
|
dbi, err := t.NewPrefixIterator(key)
|
|
|
|
if err != nil {
|
|
|
|
return err
|
|
|
|
}
|
|
|
|
defer dbi.Release()
|
|
|
|
|
|
|
|
var dk []byte
|
|
|
|
for dbi.Next() {
|
|
|
|
name := t.keyer.NameFromGlobalVersionKey(dbi.Key())
|
|
|
|
if len(prefix) > 0 && !bytes.HasPrefix(name, prefix) {
|
|
|
|
return nil
|
|
|
|
}
|
|
|
|
|
2020-03-16 02:09:27 -07:00
|
|
|
var vl VersionList
|
|
|
|
if err := vl.Unmarshal(dbi.Value()); err != nil {
|
|
|
|
return err
|
2020-01-21 10:23:08 -07:00
|
|
|
}
|
|
|
|
|
2020-05-30 00:50:23 -07:00
|
|
|
var f protocol.FileIntf
|
|
|
|
dk, f, _, err = t.getGlobalFromVersionList(dk, folder, name, truncate, vl)
|
2020-01-21 10:23:08 -07:00
|
|
|
if err != nil {
|
|
|
|
return err
|
|
|
|
}
|
|
|
|
|
|
|
|
if !fn(f) {
|
|
|
|
return nil
|
|
|
|
}
|
|
|
|
}
|
|
|
|
if err != nil {
|
|
|
|
return err
|
|
|
|
}
|
|
|
|
return dbi.Error()
|
|
|
|
}
|
|
|
|
|
2020-05-11 11:15:11 -07:00
|
|
|
func (t *readOnlyTransaction) withBlocksHash(folder, hash []byte, iterator Iterator) error {
|
|
|
|
key, err := t.keyer.GenerateBlockListMapKey(nil, folder, hash, nil)
|
|
|
|
if err != nil {
|
|
|
|
return err
|
|
|
|
}
|
|
|
|
|
|
|
|
iter, err := t.NewPrefixIterator(key)
|
|
|
|
if err != nil {
|
|
|
|
return err
|
|
|
|
}
|
|
|
|
defer iter.Release()
|
|
|
|
|
|
|
|
for iter.Next() {
|
|
|
|
file := string(t.keyer.NameFromBlockListMapKey(iter.Key()))
|
|
|
|
f, ok, err := t.getFile(folder, protocol.LocalDeviceID[:], []byte(osutil.NormalizedFilename(file)))
|
|
|
|
if err != nil {
|
|
|
|
return err
|
|
|
|
}
|
|
|
|
if !ok {
|
|
|
|
continue
|
|
|
|
}
|
|
|
|
f.Name = osutil.NativeFilename(f.Name)
|
|
|
|
|
|
|
|
if !bytes.Equal(f.BlocksHash, hash) {
|
|
|
|
l.Warnf("Mismatching block map list hashes: got %x expected %x", f.BlocksHash, hash)
|
|
|
|
continue
|
|
|
|
}
|
|
|
|
|
|
|
|
if f.IsDeleted() || f.IsInvalid() || f.IsDirectory() || f.IsSymlink() {
|
|
|
|
l.Warnf("Found something of unexpected type in block list map: %s", f)
|
|
|
|
continue
|
|
|
|
}
|
|
|
|
|
|
|
|
if !iterator(f) {
|
|
|
|
break
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
return iter.Error()
|
|
|
|
}
|
|
|
|
|
2020-01-21 10:23:08 -07:00
|
|
|
func (t *readOnlyTransaction) availability(folder, file []byte) ([]protocol.DeviceID, error) {
|
2020-05-01 00:30:20 -07:00
|
|
|
vl, err := t.getGlobalVersions(nil, folder, file)
|
2020-01-21 10:23:08 -07:00
|
|
|
if backend.IsNotFound(err) {
|
|
|
|
return nil, nil
|
|
|
|
}
|
|
|
|
if err != nil {
|
|
|
|
return nil, err
|
|
|
|
}
|
|
|
|
|
2020-05-30 00:50:23 -07:00
|
|
|
fv, ok := vl.GetGlobal()
|
|
|
|
if !ok {
|
|
|
|
return nil, nil
|
|
|
|
}
|
|
|
|
devices := make([]protocol.DeviceID, len(fv.Devices))
|
|
|
|
for i, dev := range fv.Devices {
|
2020-06-07 01:31:12 -07:00
|
|
|
n, err := protocol.DeviceIDFromBytes(dev)
|
|
|
|
if err != nil {
|
|
|
|
return nil, err
|
|
|
|
}
|
|
|
|
devices[i] = n
|
2020-01-21 10:23:08 -07:00
|
|
|
}
|
|
|
|
|
|
|
|
return devices, nil
|
|
|
|
}
|
|
|
|
|
|
|
|
func (t *readOnlyTransaction) withNeed(folder, device []byte, truncate bool, fn Iterator) error {
|
|
|
|
if bytes.Equal(device, protocol.LocalDeviceID[:]) {
|
|
|
|
return t.withNeedLocal(folder, truncate, fn)
|
|
|
|
}
|
|
|
|
|
|
|
|
key, err := t.keyer.GenerateGlobalVersionKey(nil, folder, nil)
|
|
|
|
if err != nil {
|
|
|
|
return err
|
|
|
|
}
|
|
|
|
dbi, err := t.NewPrefixIterator(key.WithoutName())
|
|
|
|
if err != nil {
|
|
|
|
return err
|
|
|
|
}
|
|
|
|
defer dbi.Release()
|
|
|
|
|
|
|
|
var dk []byte
|
2020-06-07 01:31:12 -07:00
|
|
|
devID, err := protocol.DeviceIDFromBytes(device)
|
|
|
|
if err != nil {
|
|
|
|
return err
|
|
|
|
}
|
2020-01-21 10:23:08 -07:00
|
|
|
for dbi.Next() {
|
2020-03-16 02:09:27 -07:00
|
|
|
var vl VersionList
|
|
|
|
if err := vl.Unmarshal(dbi.Value()); err != nil {
|
|
|
|
return err
|
2020-01-21 10:23:08 -07:00
|
|
|
}
|
|
|
|
|
2020-05-30 00:50:23 -07:00
|
|
|
globalFV, ok := vl.GetGlobal()
|
|
|
|
if !ok {
|
|
|
|
return errEmptyGlobal
|
|
|
|
}
|
2020-01-21 10:23:08 -07:00
|
|
|
haveFV, have := vl.Get(device)
|
|
|
|
|
2020-05-11 06:07:06 -07:00
|
|
|
if !need(globalFV, have, haveFV.Version) {
|
|
|
|
continue
|
|
|
|
}
|
2020-05-30 00:50:23 -07:00
|
|
|
|
2020-01-21 10:23:08 -07:00
|
|
|
name := t.keyer.NameFromGlobalVersionKey(dbi.Key())
|
2020-05-30 00:50:23 -07:00
|
|
|
var gf protocol.FileIntf
|
|
|
|
dk, gf, err = t.getGlobalFromFileVersion(dk, folder, name, truncate, globalFV)
|
2020-03-16 00:45:45 -07:00
|
|
|
if err != nil {
|
|
|
|
return err
|
|
|
|
}
|
2020-05-30 00:50:23 -07:00
|
|
|
|
|
|
|
globalDev, ok := globalFV.FirstDevice()
|
2020-03-16 00:45:45 -07:00
|
|
|
if !ok {
|
2020-05-30 00:50:23 -07:00
|
|
|
return errEmptyFileVersion
|
2020-03-16 00:45:45 -07:00
|
|
|
}
|
2020-05-30 00:50:23 -07:00
|
|
|
l.Debugf("need folder=%q device=%v name=%q have=%v invalid=%v haveV=%v globalV=%v globalDev=%v", folder, devID, name, have, haveFV.IsInvalid(), haveFV.Version, gf.FileVersion(), globalDev)
|
2020-03-16 00:45:45 -07:00
|
|
|
if !fn(gf) {
|
|
|
|
return dbi.Error()
|
2020-01-21 10:23:08 -07:00
|
|
|
}
|
|
|
|
}
|
|
|
|
return dbi.Error()
|
|
|
|
}
|
|
|
|
|
|
|
|
func (t *readOnlyTransaction) withNeedLocal(folder []byte, truncate bool, fn Iterator) error {
|
|
|
|
key, err := t.keyer.GenerateNeedFileKey(nil, folder, nil)
|
|
|
|
if err != nil {
|
|
|
|
return err
|
|
|
|
}
|
|
|
|
dbi, err := t.NewPrefixIterator(key.WithoutName())
|
|
|
|
if err != nil {
|
|
|
|
return err
|
|
|
|
}
|
|
|
|
defer dbi.Release()
|
|
|
|
|
|
|
|
var keyBuf []byte
|
2020-05-30 00:50:23 -07:00
|
|
|
var f protocol.FileIntf
|
2020-01-21 10:23:08 -07:00
|
|
|
var ok bool
|
|
|
|
for dbi.Next() {
|
|
|
|
keyBuf, f, ok, err = t.getGlobal(keyBuf, folder, t.keyer.NameFromGlobalVersionKey(dbi.Key()), truncate)
|
|
|
|
if err != nil {
|
|
|
|
return err
|
|
|
|
}
|
|
|
|
if !ok {
|
|
|
|
continue
|
|
|
|
}
|
|
|
|
if !fn(f) {
|
|
|
|
return nil
|
|
|
|
}
|
|
|
|
}
|
|
|
|
return dbi.Error()
|
|
|
|
}
|
|
|
|
|
2015-10-29 00:07:51 -07:00
|
|
|
// A readWriteTransaction is a readOnlyTransaction plus a batch for writes.
|
|
|
|
// The batch will be committed on close() or by checkFlush() if it exceeds the
|
|
|
|
// batch size.
|
|
|
|
type readWriteTransaction struct {
|
2019-11-29 01:11:52 -07:00
|
|
|
backend.WriteTransaction
|
2015-10-29 00:07:51 -07:00
|
|
|
readOnlyTransaction
|
|
|
|
}
|
|
|
|
|
2020-07-18 23:55:27 -07:00
|
|
|
func (db *Lowlevel) newReadWriteTransaction(hooks ...backend.CommitHook) (readWriteTransaction, error) {
|
|
|
|
tran, err := db.NewWriteTransaction(hooks...)
|
2019-11-29 01:11:52 -07:00
|
|
|
if err != nil {
|
|
|
|
return readWriteTransaction{}, err
|
2015-10-29 00:07:51 -07:00
|
|
|
}
|
2019-11-29 01:11:52 -07:00
|
|
|
return readWriteTransaction{
|
|
|
|
WriteTransaction: tran,
|
|
|
|
readOnlyTransaction: readOnlyTransaction{
|
|
|
|
ReadTransaction: tran,
|
|
|
|
keyer: db.keyer,
|
|
|
|
},
|
|
|
|
}, nil
|
|
|
|
}
|
|
|
|
|
2020-02-12 03:59:55 -07:00
|
|
|
func (t readWriteTransaction) Commit() error {
|
2020-05-29 04:43:02 -07:00
|
|
|
// The readOnlyTransaction must close after commit, because they may be
|
|
|
|
// backed by the same actual lower level transaction.
|
|
|
|
defer t.readOnlyTransaction.close()
|
2019-11-29 01:11:52 -07:00
|
|
|
return t.WriteTransaction.Commit()
|
2015-10-29 00:07:51 -07:00
|
|
|
}
|
|
|
|
|
|
|
|
func (t readWriteTransaction) close() {
|
|
|
|
t.readOnlyTransaction.close()
|
2019-11-29 01:11:52 -07:00
|
|
|
t.WriteTransaction.Release()
|
2015-10-29 00:07:51 -07:00
|
|
|
}
|
|
|
|
|
2020-03-20 04:07:14 -07:00
|
|
|
// putFile stores a file in the database, taking care of indirected fields.
|
|
|
|
// Set the truncated flag when putting a file that deliberatly can have an
|
|
|
|
// empty block list but a non-empty block list hash. This should normally be
|
|
|
|
// false.
|
|
|
|
func (t readWriteTransaction) putFile(fkey []byte, fi protocol.FileInfo, truncated bool) error {
|
2020-02-27 03:19:21 -07:00
|
|
|
var bkey []byte
|
|
|
|
|
2020-03-20 04:07:14 -07:00
|
|
|
// Always set the blocks hash when there are blocks. Leave the blocks
|
|
|
|
// hash alone when there are no blocks and we might be putting a
|
|
|
|
// "truncated" FileInfo (no blocks, but the hash reference is live).
|
2020-02-27 03:19:21 -07:00
|
|
|
if len(fi.Blocks) > 0 {
|
|
|
|
fi.BlocksHash = protocol.BlocksHash(fi.Blocks)
|
2020-03-20 04:07:14 -07:00
|
|
|
} else if !truncated {
|
2020-02-27 03:19:21 -07:00
|
|
|
fi.BlocksHash = nil
|
|
|
|
}
|
|
|
|
|
|
|
|
// Indirect the blocks if the block list is large enough.
|
|
|
|
if len(fi.Blocks) > blocksIndirectionCutoff {
|
|
|
|
bkey = t.keyer.GenerateBlockListKey(bkey, fi.BlocksHash)
|
|
|
|
if _, err := t.Get(bkey); backend.IsNotFound(err) {
|
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 00:35:44 -07:00
|
|
|
// Marshal the block list and save it
|
|
|
|
blocksBs := mustMarshal(&BlockList{Blocks: fi.Blocks})
|
2020-02-27 03:19:21 -07:00
|
|
|
if err := t.Put(bkey, blocksBs); err != nil {
|
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 00:35:44 -07:00
|
|
|
return err
|
|
|
|
}
|
|
|
|
} else if err != nil {
|
|
|
|
return err
|
|
|
|
}
|
2020-02-27 03:19:21 -07:00
|
|
|
fi.Blocks = nil
|
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 00:35:44 -07:00
|
|
|
}
|
|
|
|
|
2020-05-13 05:28:42 -07:00
|
|
|
// Indirect the version vector if it's large enough.
|
|
|
|
if len(fi.Version.Counters) > versionIndirectionCutoff {
|
|
|
|
fi.VersionHash = protocol.VectorHash(fi.Version)
|
|
|
|
bkey = t.keyer.GenerateVersionKey(bkey, fi.VersionHash)
|
|
|
|
if _, err := t.Get(bkey); backend.IsNotFound(err) {
|
|
|
|
// Marshal the version vector and save it
|
|
|
|
versionBs := mustMarshal(&fi.Version)
|
|
|
|
if err := t.Put(bkey, versionBs); err != nil {
|
|
|
|
return err
|
|
|
|
}
|
|
|
|
} else if err != nil {
|
|
|
|
return err
|
|
|
|
}
|
|
|
|
fi.Version = protocol.Vector{}
|
|
|
|
} else {
|
|
|
|
fi.VersionHash = nil
|
|
|
|
}
|
|
|
|
|
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 00:35:44 -07:00
|
|
|
fiBs := mustMarshal(&fi)
|
2020-02-27 03:19:21 -07:00
|
|
|
return t.Put(fkey, fiBs)
|
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 00:35:44 -07:00
|
|
|
}
|
|
|
|
|
2015-10-29 00:07:51 -07:00
|
|
|
// updateGlobal adds this device+version to the version list for the given
|
|
|
|
// file. If the device is already present in the list, the version is updated.
|
|
|
|
// If the file does not have an entry in the global list, it is created.
|
2019-11-29 01:11:52 -07:00
|
|
|
func (t readWriteTransaction) updateGlobal(gk, keyBuf, folder, device []byte, file protocol.FileInfo, meta *metadataTracker) ([]byte, bool, error) {
|
2020-06-07 01:31:12 -07:00
|
|
|
deviceID, err := protocol.DeviceIDFromBytes(device)
|
|
|
|
if err != nil {
|
|
|
|
return nil, false, err
|
|
|
|
}
|
2020-05-11 06:07:06 -07:00
|
|
|
|
|
|
|
l.Debugf("update global; folder=%q device=%v file=%q version=%v invalid=%v", folder, deviceID, file.Name, file.Version, file.IsInvalid())
|
2015-10-29 00:07:51 -07:00
|
|
|
|
2020-05-01 00:30:20 -07:00
|
|
|
fl, err := t.getGlobalVersionsByKey(gk)
|
|
|
|
if err != nil && !backend.IsNotFound(err) {
|
2019-11-29 01:11:52 -07:00
|
|
|
return nil, false, err
|
|
|
|
}
|
|
|
|
|
2020-05-30 00:50:23 -07:00
|
|
|
globalFV, oldGlobalFV, removedFV, haveOldGlobal, haveRemoved, globalChanged, err := fl.update(folder, device, file, t.readOnlyTransaction)
|
2019-11-29 01:11:52 -07:00
|
|
|
if err != nil {
|
|
|
|
return nil, false, err
|
2015-10-29 00:07:51 -07:00
|
|
|
}
|
|
|
|
|
2018-06-17 23:23:40 -07:00
|
|
|
name := []byte(file.Name)
|
|
|
|
|
2020-05-11 06:07:06 -07:00
|
|
|
l.Debugf(`new global for "%v" after update: %v`, file.Name, fl)
|
|
|
|
if err := t.Put(gk, mustMarshal(&fl)); err != nil {
|
|
|
|
return nil, false, err
|
|
|
|
}
|
|
|
|
|
|
|
|
// Only load those from db if actually needed
|
|
|
|
|
|
|
|
var gotGlobal, gotOldGlobal bool
|
2020-05-30 00:50:23 -07:00
|
|
|
var global, oldGlobal protocol.FileIntf
|
2018-06-02 06:08:32 -07:00
|
|
|
|
2020-05-11 06:07:06 -07:00
|
|
|
// Check the need of the device that was updated
|
|
|
|
// Must happen before updating global meta: If this is the first
|
|
|
|
// item from this device, it will be initialized with the global state.
|
|
|
|
|
|
|
|
needBefore := false
|
|
|
|
if haveOldGlobal {
|
2020-05-30 00:50:23 -07:00
|
|
|
needBefore = need(oldGlobalFV, haveRemoved, removedFV.Version)
|
2020-05-11 06:07:06 -07:00
|
|
|
}
|
2020-05-30 00:50:23 -07:00
|
|
|
needNow := need(globalFV, true, file.Version)
|
2020-05-11 06:07:06 -07:00
|
|
|
if needBefore {
|
2020-05-30 00:50:23 -07:00
|
|
|
if keyBuf, oldGlobal, err = t.getGlobalFromFileVersion(keyBuf, folder, name, true, oldGlobalFV); err != nil {
|
2020-05-13 03:56:49 -07:00
|
|
|
return nil, false, err
|
2020-05-11 06:07:06 -07:00
|
|
|
}
|
2020-05-13 03:56:49 -07:00
|
|
|
gotOldGlobal = true
|
2020-05-11 06:07:06 -07:00
|
|
|
meta.removeNeeded(deviceID, oldGlobal)
|
|
|
|
if !needNow && bytes.Equal(device, protocol.LocalDeviceID[:]) {
|
|
|
|
if keyBuf, err = t.updateLocalNeed(keyBuf, folder, name, false); err != nil {
|
|
|
|
return nil, false, err
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
if needNow {
|
2020-05-30 00:50:23 -07:00
|
|
|
if keyBuf, global, err = t.updateGlobalGetGlobal(keyBuf, folder, name, file, globalFV); err != nil {
|
2020-05-13 03:56:49 -07:00
|
|
|
return nil, false, err
|
2020-05-11 06:07:06 -07:00
|
|
|
}
|
2020-05-13 03:56:49 -07:00
|
|
|
gotGlobal = true
|
2020-05-11 06:07:06 -07:00
|
|
|
meta.addNeeded(deviceID, global)
|
|
|
|
if !needBefore && bytes.Equal(device, protocol.LocalDeviceID[:]) {
|
|
|
|
if keyBuf, err = t.updateLocalNeed(keyBuf, folder, name, true); err != nil {
|
|
|
|
return nil, false, err
|
|
|
|
}
|
|
|
|
}
|
2019-11-29 01:11:52 -07:00
|
|
|
}
|
2015-10-29 00:07:51 -07:00
|
|
|
|
2020-07-30 04:49:14 -07:00
|
|
|
// Update global size counter if necessary
|
|
|
|
|
|
|
|
if !globalChanged {
|
|
|
|
// Neither the global state nor the needs of any devices, except
|
|
|
|
// the one updated, changed.
|
|
|
|
return keyBuf, true, nil
|
|
|
|
}
|
2020-05-13 03:56:49 -07:00
|
|
|
|
|
|
|
// Remove the old global from the global size counter
|
|
|
|
if haveOldGlobal {
|
|
|
|
if !gotOldGlobal {
|
2020-05-30 00:50:23 -07:00
|
|
|
if keyBuf, oldGlobal, err = t.getGlobalFromFileVersion(keyBuf, folder, name, true, oldGlobalFV); err != nil {
|
2020-05-11 06:07:06 -07:00
|
|
|
return nil, false, err
|
|
|
|
}
|
|
|
|
gotOldGlobal = true
|
|
|
|
}
|
2020-05-30 00:50:23 -07:00
|
|
|
// Remove the old global from the global size counter
|
2020-05-13 03:56:49 -07:00
|
|
|
meta.removeFile(protocol.GlobalDeviceID, oldGlobal)
|
2020-05-11 06:07:06 -07:00
|
|
|
}
|
|
|
|
|
2020-05-13 03:56:49 -07:00
|
|
|
// Add the new global to the global size counter
|
|
|
|
if !gotGlobal {
|
2020-05-30 00:50:23 -07:00
|
|
|
if keyBuf, global, err = t.updateGlobalGetGlobal(keyBuf, folder, name, file, globalFV); err != nil {
|
2020-05-13 03:56:49 -07:00
|
|
|
return nil, false, err
|
|
|
|
}
|
|
|
|
gotGlobal = true
|
2018-07-10 08:32:34 -07:00
|
|
|
}
|
2020-05-13 03:56:49 -07:00
|
|
|
meta.addFile(protocol.GlobalDeviceID, global)
|
2018-07-10 08:32:34 -07:00
|
|
|
|
2020-05-11 06:07:06 -07:00
|
|
|
// check for local (if not already done before)
|
|
|
|
if !bytes.Equal(device, protocol.LocalDeviceID[:]) {
|
|
|
|
localFV, haveLocal := fl.Get(protocol.LocalDeviceID[:])
|
|
|
|
needBefore := false
|
|
|
|
if haveOldGlobal {
|
|
|
|
needBefore = need(oldGlobalFV, haveLocal, localFV.Version)
|
|
|
|
}
|
|
|
|
needNow := need(globalFV, haveLocal, localFV.Version)
|
|
|
|
if needBefore {
|
|
|
|
meta.removeNeeded(protocol.LocalDeviceID, oldGlobal)
|
|
|
|
if !needNow {
|
|
|
|
if keyBuf, err = t.updateLocalNeed(keyBuf, folder, name, false); err != nil {
|
|
|
|
return nil, false, err
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
if need(globalFV, haveLocal, localFV.Version) {
|
|
|
|
meta.addNeeded(protocol.LocalDeviceID, global)
|
|
|
|
if !needBefore {
|
|
|
|
if keyBuf, err = t.updateLocalNeed(keyBuf, folder, name, true); err != nil {
|
|
|
|
return nil, false, err
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
for _, dev := range meta.devices() {
|
|
|
|
if bytes.Equal(dev[:], device) {
|
|
|
|
// Already handled above
|
|
|
|
continue
|
|
|
|
}
|
|
|
|
fv, have := fl.Get(dev[:])
|
|
|
|
if haveOldGlobal && need(oldGlobalFV, have, fv.Version) {
|
|
|
|
meta.removeNeeded(dev, oldGlobal)
|
|
|
|
}
|
|
|
|
if need(globalFV, have, fv.Version) {
|
|
|
|
meta.addNeeded(dev, global)
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
return keyBuf, true, nil
|
|
|
|
}
|
|
|
|
|
2020-05-30 00:50:23 -07:00
|
|
|
func (t readWriteTransaction) updateGlobalGetGlobal(keyBuf, folder, name []byte, file protocol.FileInfo, fv FileVersion) ([]byte, protocol.FileIntf, error) {
|
|
|
|
if fv.Version.Equal(file.Version) {
|
2020-05-11 06:07:06 -07:00
|
|
|
// Inserted a new newest version
|
2020-05-30 00:50:23 -07:00
|
|
|
return keyBuf, file, nil
|
2019-11-29 01:11:52 -07:00
|
|
|
}
|
2020-05-30 00:50:23 -07:00
|
|
|
return t.getGlobalFromFileVersion(keyBuf, folder, name, true, fv)
|
2015-10-29 00:07:51 -07:00
|
|
|
}
|
|
|
|
|
2020-05-11 06:07:06 -07:00
|
|
|
func (t readWriteTransaction) updateLocalNeed(keyBuf, folder, name []byte, add bool) ([]byte, error) {
|
2019-11-29 01:11:52 -07:00
|
|
|
var err error
|
|
|
|
keyBuf, err = t.keyer.GenerateNeedFileKey(keyBuf, folder, name)
|
|
|
|
if err != nil {
|
|
|
|
return nil, err
|
|
|
|
}
|
2020-05-11 06:07:06 -07:00
|
|
|
if add {
|
|
|
|
l.Debugf("local need insert; folder=%q, name=%q", folder, name)
|
|
|
|
err = t.Put(keyBuf, nil)
|
|
|
|
} else {
|
2018-10-29 21:40:51 -07:00
|
|
|
l.Debugf("local need delete; folder=%q, name=%q", folder, name)
|
2020-05-11 06:07:06 -07:00
|
|
|
err = t.Delete(keyBuf)
|
2018-10-29 21:40:51 -07:00
|
|
|
}
|
2020-05-11 06:07:06 -07:00
|
|
|
return keyBuf, err
|
2018-10-29 21:40:51 -07:00
|
|
|
}
|
|
|
|
|
2020-05-11 06:07:06 -07:00
|
|
|
func need(global FileVersion, haveLocal bool, localVersion protocol.Vector) bool {
|
2018-06-02 06:08:32 -07:00
|
|
|
// We never need an invalid file.
|
2020-05-30 00:50:23 -07:00
|
|
|
if global.IsInvalid() {
|
2018-06-02 06:08:32 -07:00
|
|
|
return false
|
|
|
|
}
|
|
|
|
// We don't need a deleted file if we don't have it.
|
2020-05-11 06:07:06 -07:00
|
|
|
if global.Deleted && !haveLocal {
|
2018-06-02 06:08:32 -07:00
|
|
|
return false
|
|
|
|
}
|
|
|
|
// We don't need the global file if we already have the same version.
|
2020-05-11 06:07:06 -07:00
|
|
|
if haveLocal && localVersion.GreaterEqual(global.Version) {
|
2018-06-02 06:08:32 -07:00
|
|
|
return false
|
|
|
|
}
|
|
|
|
return true
|
|
|
|
}
|
|
|
|
|
2015-10-29 00:07:51 -07:00
|
|
|
// removeFromGlobal removes the device from the global version list for the
|
|
|
|
// given file. If the version list is empty after this, the file entry is
|
|
|
|
// removed entirely.
|
2020-05-30 00:50:23 -07:00
|
|
|
func (t readWriteTransaction) removeFromGlobal(gk, keyBuf, folder, device, file []byte, meta *metadataTracker) ([]byte, error) {
|
2020-06-07 01:31:12 -07:00
|
|
|
deviceID, err := protocol.DeviceIDFromBytes(device)
|
|
|
|
if err != nil {
|
|
|
|
return nil, err
|
|
|
|
}
|
2020-05-11 06:07:06 -07:00
|
|
|
|
|
|
|
l.Debugf("remove from global; folder=%q device=%v file=%q", folder, deviceID, file)
|
2015-10-29 00:07:51 -07:00
|
|
|
|
2020-05-01 00:30:20 -07:00
|
|
|
fl, err := t.getGlobalVersionsByKey(gk)
|
2019-11-29 01:11:52 -07:00
|
|
|
if backend.IsNotFound(err) {
|
2015-10-29 00:07:51 -07:00
|
|
|
// We might be called to "remove" a global version that doesn't exist
|
|
|
|
// if the first update for the file is already marked invalid.
|
2019-11-29 01:11:52 -07:00
|
|
|
return keyBuf, nil
|
|
|
|
} else if err != nil {
|
|
|
|
return nil, err
|
2015-10-29 00:07:51 -07:00
|
|
|
}
|
|
|
|
|
2020-05-30 00:50:23 -07:00
|
|
|
oldGlobalFV, haveOldGlobal := fl.GetGlobal()
|
|
|
|
|
|
|
|
if !haveOldGlobal {
|
2020-05-13 03:56:49 -07:00
|
|
|
// Shouldn't ever happen, but doesn't hurt to handle.
|
|
|
|
return keyBuf, t.Delete(gk)
|
|
|
|
}
|
|
|
|
|
2020-05-30 00:50:23 -07:00
|
|
|
removedFV, haveRemoved, globalChanged, err := fl.pop(folder, device, file, t.readOnlyTransaction)
|
|
|
|
if err != nil {
|
|
|
|
return nil, err
|
|
|
|
}
|
|
|
|
if !haveRemoved {
|
2018-10-29 21:40:51 -07:00
|
|
|
// There is no version for the given device
|
2019-11-29 01:11:52 -07:00
|
|
|
return keyBuf, nil
|
2018-10-29 21:40:51 -07:00
|
|
|
}
|
|
|
|
|
2020-05-30 00:50:23 -07:00
|
|
|
var global protocol.FileIntf
|
2020-05-13 03:56:49 -07:00
|
|
|
var gotGlobal, ok bool
|
|
|
|
|
2020-05-30 00:50:23 -07:00
|
|
|
globalFV, ok := fl.GetGlobal()
|
2020-05-13 03:56:49 -07:00
|
|
|
// Add potential needs of the removed device
|
2020-05-30 00:50:23 -07:00
|
|
|
if ok && !globalFV.IsInvalid() && need(globalFV, false, protocol.Vector{}) && !need(oldGlobalFV, haveRemoved, removedFV.Version) {
|
|
|
|
keyBuf, global, _, err = t.getGlobalFromVersionList(keyBuf, folder, file, true, fl)
|
2020-05-13 03:56:49 -07:00
|
|
|
if err != nil {
|
|
|
|
return nil, err
|
|
|
|
}
|
|
|
|
gotGlobal = true
|
|
|
|
meta.addNeeded(deviceID, global)
|
|
|
|
if bytes.Equal(protocol.LocalDeviceID[:], device) {
|
|
|
|
if keyBuf, err = t.updateLocalNeed(keyBuf, folder, file, true); err != nil {
|
|
|
|
return nil, err
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
// Global hasn't changed, abort early
|
2020-05-30 00:50:23 -07:00
|
|
|
if !globalChanged {
|
2020-05-11 06:07:06 -07:00
|
|
|
l.Debugf("new global after remove: %v", fl)
|
|
|
|
if err := t.Put(gk, mustMarshal(&fl)); err != nil {
|
2020-03-19 06:32:22 -07:00
|
|
|
return nil, err
|
2015-10-29 00:07:51 -07:00
|
|
|
}
|
2020-05-13 03:56:49 -07:00
|
|
|
return keyBuf, nil
|
2015-10-29 00:07:51 -07:00
|
|
|
}
|
|
|
|
|
2020-07-30 04:49:14 -07:00
|
|
|
var f protocol.FileIntf
|
|
|
|
keyBuf, f, err = t.getGlobalFromFileVersion(keyBuf, folder, file, true, oldGlobalFV)
|
2020-05-11 06:07:06 -07:00
|
|
|
if err != nil {
|
|
|
|
return nil, err
|
|
|
|
}
|
|
|
|
meta.removeFile(protocol.GlobalDeviceID, f)
|
|
|
|
|
2020-05-13 03:56:49 -07:00
|
|
|
// Remove potential device needs
|
2020-05-11 06:07:06 -07:00
|
|
|
if fv, have := fl.Get(protocol.LocalDeviceID[:]); need(removedFV, have, fv.Version) {
|
|
|
|
meta.removeNeeded(protocol.LocalDeviceID, f)
|
|
|
|
if keyBuf, err = t.updateLocalNeed(keyBuf, folder, file, false); err != nil {
|
2019-11-29 01:11:52 -07:00
|
|
|
return nil, err
|
|
|
|
}
|
2020-05-11 06:07:06 -07:00
|
|
|
}
|
|
|
|
for _, dev := range meta.devices() {
|
2020-05-13 03:56:49 -07:00
|
|
|
if bytes.Equal(dev[:], device) { // Was the previous global
|
2020-05-11 06:07:06 -07:00
|
|
|
continue
|
|
|
|
}
|
|
|
|
if fv, have := fl.Get(dev[:]); need(removedFV, have, fv.Version) {
|
|
|
|
meta.removeNeeded(deviceID, f)
|
2019-11-29 01:11:52 -07:00
|
|
|
}
|
2020-05-11 06:07:06 -07:00
|
|
|
}
|
|
|
|
|
2020-05-13 03:56:49 -07:00
|
|
|
// Nothing left, i.e. nothing to add to the global counter below.
|
2020-05-30 00:50:23 -07:00
|
|
|
if fl.Empty() {
|
2019-11-29 01:11:52 -07:00
|
|
|
if err := t.Delete(gk); err != nil {
|
|
|
|
return nil, err
|
|
|
|
}
|
|
|
|
return keyBuf, nil
|
2017-11-11 12:18:17 -07:00
|
|
|
}
|
2018-10-29 21:40:51 -07:00
|
|
|
|
2020-05-13 03:56:49 -07:00
|
|
|
// Add to global
|
|
|
|
if !gotGlobal {
|
2020-05-30 00:50:23 -07:00
|
|
|
keyBuf, global, _, err = t.getGlobalFromVersionList(keyBuf, folder, file, true, fl)
|
2020-05-13 03:56:49 -07:00
|
|
|
if err != nil {
|
|
|
|
return nil, err
|
2019-11-29 01:11:52 -07:00
|
|
|
}
|
2015-10-29 00:07:51 -07:00
|
|
|
}
|
2020-05-13 03:56:49 -07:00
|
|
|
meta.addFile(protocol.GlobalDeviceID, global)
|
2018-10-29 21:40:51 -07:00
|
|
|
|
2020-05-30 00:50:23 -07:00
|
|
|
l.Debugf(`new global for "%s" after remove: %v`, file, fl)
|
2019-11-29 01:11:52 -07:00
|
|
|
if err := t.Put(gk, mustMarshal(&fl)); err != nil {
|
|
|
|
return nil, err
|
|
|
|
}
|
2019-01-20 00:47:20 -07:00
|
|
|
|
2019-11-29 01:11:52 -07:00
|
|
|
return keyBuf, nil
|
2015-10-29 00:07:51 -07:00
|
|
|
}
|
|
|
|
|
2019-11-29 01:11:52 -07:00
|
|
|
func (t readWriteTransaction) deleteKeyPrefix(prefix []byte) error {
|
|
|
|
dbi, err := t.NewPrefixIterator(prefix)
|
|
|
|
if err != nil {
|
|
|
|
return err
|
|
|
|
}
|
|
|
|
defer dbi.Release()
|
2018-06-02 06:08:32 -07:00
|
|
|
for dbi.Next() {
|
2019-11-29 01:11:52 -07:00
|
|
|
if err := t.Delete(dbi.Key()); err != nil {
|
|
|
|
return err
|
|
|
|
}
|
2018-06-02 06:08:32 -07:00
|
|
|
}
|
2019-11-29 01:11:52 -07:00
|
|
|
return dbi.Error()
|
2015-10-29 00:07:51 -07:00
|
|
|
}
|
2016-07-04 03:40:29 -07:00
|
|
|
|
2020-01-21 10:23:08 -07:00
|
|
|
func (t *readWriteTransaction) withAllFolderTruncated(folder []byte, fn func(device []byte, f FileInfoTruncated) bool) error {
|
|
|
|
key, err := t.keyer.GenerateDeviceFileKey(nil, folder, nil, nil)
|
|
|
|
if err != nil {
|
|
|
|
return err
|
|
|
|
}
|
|
|
|
dbi, err := t.NewPrefixIterator(key.WithoutNameAndDevice())
|
|
|
|
if err != nil {
|
|
|
|
return err
|
|
|
|
}
|
|
|
|
defer dbi.Release()
|
|
|
|
|
|
|
|
var gk, keyBuf []byte
|
|
|
|
for dbi.Next() {
|
|
|
|
device, ok := t.keyer.DeviceFromDeviceFileKey(dbi.Key())
|
|
|
|
if !ok {
|
|
|
|
// Not having the device in the index is bad. Clear it.
|
|
|
|
if err := t.Delete(dbi.Key()); err != nil {
|
|
|
|
return err
|
|
|
|
}
|
|
|
|
continue
|
|
|
|
}
|
2020-02-27 03:19:21 -07:00
|
|
|
|
|
|
|
intf, err := t.unmarshalTrunc(dbi.Value(), true)
|
2020-01-21 10:23:08 -07:00
|
|
|
if err != nil {
|
|
|
|
return err
|
|
|
|
}
|
2020-02-27 03:19:21 -07:00
|
|
|
f := intf.(FileInfoTruncated)
|
2020-01-21 10:23:08 -07:00
|
|
|
|
|
|
|
switch f.Name {
|
|
|
|
case "", ".", "..", "/": // A few obviously invalid filenames
|
|
|
|
l.Infof("Dropping invalid filename %q from database", f.Name)
|
|
|
|
name := []byte(f.Name)
|
|
|
|
gk, err = t.keyer.GenerateGlobalVersionKey(gk, folder, name)
|
|
|
|
if err != nil {
|
|
|
|
return err
|
|
|
|
}
|
|
|
|
keyBuf, err = t.removeFromGlobal(gk, keyBuf, folder, device, name, nil)
|
|
|
|
if err != nil {
|
|
|
|
return err
|
|
|
|
}
|
|
|
|
if err := t.Delete(dbi.Key()); err != nil {
|
|
|
|
return err
|
|
|
|
}
|
|
|
|
continue
|
|
|
|
}
|
|
|
|
|
|
|
|
if !fn(device, f) {
|
|
|
|
return nil
|
|
|
|
}
|
|
|
|
}
|
2020-02-14 00:11:24 -07:00
|
|
|
return dbi.Error()
|
2020-01-21 10:23:08 -07:00
|
|
|
}
|
|
|
|
|
2016-07-04 03:40:29 -07:00
|
|
|
type marshaller interface {
|
|
|
|
Marshal() ([]byte, error)
|
|
|
|
}
|
|
|
|
|
|
|
|
func mustMarshal(f marshaller) []byte {
|
|
|
|
bs, err := f.Marshal()
|
|
|
|
if err != nil {
|
|
|
|
panic(err)
|
|
|
|
}
|
|
|
|
return bs
|
|
|
|
}
|