Go to file
Thomas Lamprecht 18934ae56b api: namespace management endpoints
allow to list any namespace with privileges on it and allow to create
and delete namespaces if the user has modify permissions on the parent
namespace.

Creation is only allowed if the parent NS already exists.

Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
2022-05-12 09:33:50 +02:00
.cargo cargo: switch to use packaged crates by default 2020-01-03 09:40:33 +01:00
debian update proxmox-http b-d to 0.6.1 2022-05-05 10:50:49 +02:00
docs fix #3067: docs: add markdown primer from pve to pbs 2022-04-25 08:39:39 +02:00
etc update enterprise repository to bullseye 2021-06-28 19:57:50 +02:00
examples api-types: add namespace to BackupGroup 2022-05-12 09:33:50 +02:00
pbs-api-types api: namespace management endpoints 2022-05-12 09:33:50 +02:00
pbs-buildcfg bump version to 2.1.8-1 2022-05-02 17:36:22 +02:00
pbs-client pbs-client: don't include empty backup-ns in requests 2022-05-12 09:33:50 +02:00
pbs-config api: namespace management endpoints 2022-05-12 09:33:50 +02:00
pbs-datastore datastore: add max-depth to recursive namespace iter 2022-05-12 09:33:50 +02:00
pbs-fuse-loop pbs fuse loop: rust fmt 2022-04-06 16:59:54 +02:00
pbs-tape pbs-tape: sgutils2: check sense data when status is 'CHECK_CONDITION' 2022-04-21 09:35:52 +02:00
pbs-tools tools: rustfmt 2022-04-14 14:05:17 +02:00
proxmox-backup-banner issue banner: avoid depending on proxmox crate for hostname 2021-07-19 16:32:50 +02:00
proxmox-backup-client client: add --ns parameter to snapshot list 2022-05-12 09:33:50 +02:00
proxmox-file-restore api-types: add namespace to BackupGroup 2022-05-12 09:33:50 +02:00
proxmox-rest-server bump proxmox-compression dependency to 0.1.1 2022-04-13 09:37:20 +02:00
proxmox-restore-daemon cargo fmt 2022-04-28 10:26:00 +02:00
proxmox-rrd bump proxmox-schema dependency to 1.3.1 for streaming attribute 2022-04-13 08:20:27 +02:00
pxar-bin bump proxmox-schema dependency to 1.3.1 for streaming attribute 2022-04-13 08:20:27 +02:00
src api: namespace management endpoints 2022-05-12 09:33:50 +02:00
tests make datastore BackupGroup/Dir ctors private 2022-04-20 11:56:23 +02:00
www ui: add tooltip to datastore in maintenance mode 2022-04-27 19:21:19 +02:00
zsh-completions zsh: fix completions 2021-09-03 10:29:48 +02:00
.gitignore .gitignore: do not ingnor .html files - we have some of them in the repository 2021-02-21 10:04:52 +01:00
Cargo.toml update proxmox-http b-d to 0.6.1 2022-05-05 10:50:49 +02:00
Makefile buildsys: drop hack that moved testing after dh_install 2021-12-15 14:25:32 +01:00
README.rst README: update for bullseye 2022-01-26 16:19:21 +01:00
TODO.rst tape: add/use rust scsi changer implementation using libsgutil2 2021-01-25 13:14:07 +01:00
defines.mk docs: add datastore.cfg.5 man page 2021-02-10 11:05:02 +01:00
rustfmt.toml import rustfmt.toml 2019-08-22 13:44:57 +02:00

README.rst

Build & Release Notes
*********************

``rustup`` Toolchain
====================

We normally want to build with the ``rustc`` Debian package. To do that
you can set the following ``rustup`` configuration:

    # rustup toolchain link system /usr
    # rustup default system


Versioning of proxmox helper crates
===================================

To use current git master code of the proxmox* helper crates, add::

   git = "git://git.proxmox.com/git/proxmox"

or::

   path = "../proxmox/proxmox"

to the proxmox dependency, and update the version to reflect the current,
pre-release version number (e.g., "0.1.1-dev.1" instead of "0.1.0").


Local cargo config
==================

This repository ships with a ``.cargo/config`` that replaces the crates.io
registry with packaged crates located in ``/usr/share/cargo/registry``.

A similar config is also applied building with dh_cargo. Cargo.lock needs to be
deleted when switching between packaged crates and crates.io, since the
checksums are not compatible.

To reference new dependencies (or updated versions) that are not yet packaged,
the dependency needs to point directly to a path or git source (e.g., see
example for proxmox crate above).


Build
=====
on Debian 11 Bullseye

Setup:
  1. # echo 'deb http://download.proxmox.com/debian/devel/ bullseye main' | sudo tee /etc/apt/sources.list.d/proxmox-devel.list
  2. # sudo wget https://enterprise.proxmox.com/debian/proxmox-release-bullseye.gpg -O /etc/apt/trusted.gpg.d/proxmox-release-bullseye.gpg
  3. # sudo apt update
  4. # sudo apt install devscripts debcargo clang
  5. # git clone git://git.proxmox.com/git/proxmox-backup.git
  6. # cd proxmox-backup; sudo mk-build-deps -ir

Note: 2. may be skipped if you already added the PVE or PBS package repository

You are now able to build using the Makefile or cargo itself, e.g.::

  # make deb-all
  # # or for a non-package build
  # cargo build --all --release

Design Notes
************

Here are some random thought about the software design (unless I find a better place).


Large chunk sizes
=================

It is important to notice that large chunk sizes are crucial for performance.
We have a multi-user system, where different people can do different operations
on a datastore at the same time, and most operation involves reading a series
of chunks.

So what is the maximal theoretical speed we can get when reading a series of
chunks? Reading a chunk sequence need the following steps:

- seek to the first chunk's start location
- read the chunk data
- seek to the next chunk's start location
- read the chunk data
- ...

Lets use the following disk performance metrics:

:AST: Average Seek Time (second)
:MRS: Maximum sequential Read Speed (bytes/second)
:ACS: Average Chunk Size (bytes)

The maximum performance you can get is::

  MAX(ACS) = ACS /(AST + ACS/MRS)

Please note that chunk data is likely to be sequential arranged on disk, but
this it is sort of a best case assumption.

For a typical rotational disk, we assume the following values::

  AST: 10ms
  MRS: 170MB/s

  MAX(4MB)  = 115.37 MB/s
  MAX(1MB)  =  61.85 MB/s;
  MAX(64KB) =   6.02 MB/s;
  MAX(4KB)  =   0.39 MB/s;
  MAX(1KB)  =   0.10 MB/s;

Modern SSD are much faster, lets assume the following::

  max IOPS: 20000 => AST = 0.00005
  MRS: 500Mb/s

  MAX(4MB)  = 474 MB/s
  MAX(1MB)  = 465 MB/s;
  MAX(64KB) = 354 MB/s;
  MAX(4KB)  =  67 MB/s;
  MAX(1KB)  =  18 MB/s;


Also, the average chunk directly relates to the number of chunks produced by
a backup::

  CHUNK_COUNT = BACKUP_SIZE / ACS

Here are some staticics from my developer worstation::

  Disk Usage:       65 GB
  Directories:   58971
  Files:        726314
  Files < 64KB: 617541

As you see, there are really many small files. If we would do file
level deduplication, i.e. generate one chunk per file, we end up with
more than 700000 chunks.

Instead, our current algorithm only produce large chunks with an
average chunks size of 4MB. With above data, this produce about 15000
chunks (factor 50 less chunks).