From 6ec36b470a039e9037f01a496c53ea4e24347656 Mon Sep 17 00:00:00 2001 From: Christopher Hoffman Date: Mon, 3 Nov 2025 16:47:55 +0000 Subject: [PATCH] doc: Add fscrypt documentation Signed-off-by: Christopher Hoffman --- doc/cephfs/cephfs_fscrypt_multiclient.svg | 4 + doc/cephfs/cephfs_fscrypt_overview.svg | 4 + doc/cephfs/client-config-ref.rst | 2 + doc/cephfs/fs-volumes.rst | 11 +- doc/cephfs/fscrypt.rst | 186 ++++++++++++++++++ doc/dev/cephfs-fscrypt.rst | 102 ++++++++++ doc/dev/cephfs_fscrypt_rmw_3blocks.svg | 4 + .../cephfs_fscrypt_rmw_partially_aligned.svg | 4 + doc/dev/cephfs_fscrypt_truncate_handshake.svg | 4 + 9 files changed, 318 insertions(+), 3 deletions(-) create mode 100644 doc/cephfs/cephfs_fscrypt_multiclient.svg create mode 100644 doc/cephfs/cephfs_fscrypt_overview.svg create mode 100644 doc/cephfs/fscrypt.rst create mode 100644 doc/dev/cephfs-fscrypt.rst create mode 100644 doc/dev/cephfs_fscrypt_rmw_3blocks.svg create mode 100644 doc/dev/cephfs_fscrypt_rmw_partially_aligned.svg create mode 100644 doc/dev/cephfs_fscrypt_truncate_handshake.svg diff --git a/doc/cephfs/cephfs_fscrypt_multiclient.svg b/doc/cephfs/cephfs_fscrypt_multiclient.svg new file mode 100644 index 00000000000..127c2d0c4f3 --- /dev/null +++ b/doc/cephfs/cephfs_fscrypt_multiclient.svg @@ -0,0 +1,4 @@ + + + +
FSCrypt enabled clients
Client 1
MDS
Client 2
Regular Unlocked Access
Locked Access
FSCrypt Unaware Clients
Client 3
Can view encrypted version only
 \ No newline at end of file diff --git a/doc/cephfs/cephfs_fscrypt_overview.svg b/doc/cephfs/cephfs_fscrypt_overview.svg new file mode 100644 index 00000000000..09c59a1a2c3 --- /dev/null +++ b/doc/cephfs/cephfs_fscrypt_overview.svg @@ -0,0 +1,4 @@ + + + +
FSCrypt enabled client
Client
encdir1
encfile1
encfile2
encdira
encfilea
encfileb
regdir
foo
bar
Filesystem: cephfs
 \ No newline at end of file diff --git a/doc/cephfs/client-config-ref.rst b/doc/cephfs/client-config-ref.rst index 2729d104469..8539a0f11c2 100644 --- a/doc/cephfs/client-config-ref.rst +++ b/doc/cephfs/client-config-ref.rst @@ -38,6 +38,8 @@ Client Config Reference .. confval:: client_caps_release_delay .. confval:: client_debug_force_sync_read .. confval:: client_dirsize_rbytes +.. confval:: client_fscrypt_as +.. confval:: client_fscrypt_dummy_encryption .. confval:: client_max_inline_size .. confval:: client_metadata .. confval:: client_mount_gid diff --git a/doc/cephfs/fs-volumes.rst b/doc/cephfs/fs-volumes.rst index e372f4b082c..d4ad5213286 100644 --- a/doc/cephfs/fs-volumes.rst +++ b/doc/cephfs/fs-volumes.rst @@ -380,9 +380,14 @@ file. The case of the file name used when the file was created is preserved. .. note:: Setting ``--casesensitive=0`` option implicitly enables Unicode normalization on the subvolume. -A separate encryption tag is available for use with encryption. This is to be used tagging the subvolume with -an identifier that is useful for system administrators or other services. By default, the tag is empty. This tag -is not required, but can be a useful step in setting up encrypted subvolumes. +A separate encryption tag is available for use with encryption. This is to be used +tagging the subvolume with an identifier that is useful for system administrators +or other services. By default, the tag is empty and optional. + +The encryption tag can be used to identify a subvolume to its associated encryption +master key and policy. One can map the value of enctag with a corresponding master +key. This can then be used to unlock the subvolume. This master key may be stored +in a secure location such as a key management server. Removing a Subvolume ~~~~~~~~~~~~~~~~~~~~ diff --git a/doc/cephfs/fscrypt.rst b/doc/cephfs/fscrypt.rst new file mode 100644 index 00000000000..ae9e6b9e964 --- /dev/null +++ b/doc/cephfs/fscrypt.rst @@ -0,0 +1,186 @@ +.. _fscrypt: + +Fscrypt Encryption on CephFS +========================================================== + +Fscrypt is an encryption implementation at the file system level. This file +system encryption allows for encrypting on a per directory level. This allows +for file systems to have encrypted and regular non-encrypted portions. Fscrypt +encryption encrypts file names and data contents. + +How fscrypt encryption works +------------- + +Encryption keys +~~~~~~~~~~~~ + +Each fscrypt tree has a master encryption key. This master key, will provide the +“secret” that is needed to encrypt directories. This key can be up to 256 bits +in length. + +Policies +~~~~~~~~~~~~ + +An fscrypt root is assigned an encryption policy. This policy contains items such +as which encryption cipher to use and a master key id. This tells the client how +to encrypt/decrypt and to validate a given master key id to the encrypted inode. + +Encryption happens completely on the client side. The mds and osd are not aware +of encryption policies or master keys. There has been minimal change to those +server components. They continue for the most part to store file names and data +contents (in this case happen to be encrypted). + +Access Semantics +~~~~~~~~~~~~ + +There are semantics that allow different access depending on if the client has +the master key present for a directory or not. + +With the key + +* You can access the filesystem as you normally would. +* You can see filenames, data contents and link targets. + +Without the key + +* You do not see plaintext file names or link targets. +* You cannot open a file. +* You cannot access data contents in any form, not even the encrypted versions. +* You cannot truncate a file. +* You will see other metadata such as times, mode, ownership, and extended attributes. + +.. note:: + You cannot backup or restore without the key + +Learning by example +~~~~~~~~~~~~ + +Consider a filesystem named cephfs. A client has two master keys and two +directories (encdir1 and encdira). Each directory can have a different encryption +master key. For example, encdir1 can have ``key1`` and then encdira can use ``keyb``. +Then a regular directory will also be present. Please note that regdir is an +unencrypted directory and shown for multi-tenant purposes. Figure 1 below +illustrates this. + +When a policy is set on the directory, the directory must be empty. Then any subsequent +directories, files or links created in the subtree will inherit policy information +from its parent directory. + +.. image:: cephfs_fscrypt_overview.svg +Figure 1 + +Key Management +------------- + +Each client has a unique view of a the filesystem and the fscrypt tree. For this +example please refer to Figure 2 below. There are three clients, the first two +has a newer version of the CephFS client that includes the fscrypt feature +and the third does not. The key management of the keys are on a per-client basis. +What one client does pertaining to fscrypt the other is not aware of. Let's take +a closer look to see the nuances in detail. + +The first client, Client 1, has the master key present and is able to view the +encrypted tree transparently, this is the unlocked mode. + +The second, Client 2, does not have the master key and does not have full +functionality, this is the locked mode. During locked mode, users cannot view +plaintext filenames or data contents. When a user does things list listdir, it +will see a hashed version of the encrypted file name. Then when an open() occurs, +an error will be returned and operation will be denied. Things such as file +sizes, mode, timestamps and other inode metadata will be stored plaintext and +available in this mode. + +Finally, Client 3, is using an older version of CephFS client and does not have +fscrypt feature present. In this mode, users have the same view as before, but +are able to do some data operations to encrypted files. This mode is not +recommend and not supported. + +.. image:: cephfs_fscrypt_multiclient.svg +Figure 2 + +CephFS Support +------------- + +There are two implementations of fscrypt within CephFS. It is supported in the +CephFS kernel client. This implementation extends capabilities that exist within +the kernel libraries utilizes the crypto keyring. + +Secondly, the userspace client supports fscrypt within ceph-fuse and libcephfs. +Both of these versions are meant to be inter-operable, but with some limitations. + +Userspace limitations +------------- + +A custom fscrypt cli will be needed to use userspace fscrypt. This is due to +permanent configurations in the kernel (which ceph-fuse utilize) are incorrectly +defined. Instead, there’s a fscrypt command line utility that is maintained that +is part of the ceph project. This version includes necessary changes to configure +and use fscrypt. + +This version is available at: https://github.com/ceph/fscrypt/tree/wip-ceph-fuse + +Currently a subset of fscrypt ciphers are supported in user space. +They are +AES-256-XTS for contents +AES-256-CBC-CTS for filenames +Any other ciphers used during setting policy on a folder, will be rejected. + +How to use +------------- + +Setup system wide encryption. This will initialize /etc/fscrypt.conf + +.. code:: + + $ fscrypt setup + +Setup mount wide encryption. This has to be applied to the mount point for the +filesystem. This will setup internal fscrypt cli config files for managing and +keeping track of encryption keys + +.. code:: + + $ fscrypt setup + +To setup a dir to be encrypted (it must be empty) + +.. code:: + + $ fscrypt encrypt + +To lock an encrypted dir + +.. code:: + + $ fscrypt lock + +To unlock an encrypted dir + +.. code:: + + $ fscrypt unlock + +To view status of a directory (it can be a regular or encrypted dir) + +.. code:: + + $ fscrypt status + +Behavior of master key in snapshots and clones +------------- + +All snapshots and clones derived from an fscrypt directory will have their lock +state tied together. This means that all derived datasets will be locked or +unlocked at the same time. + +For example, consider: +encrypted encdir1 is unlocked +snapshot of encdir1 is created encdir1_snap +clone of snapshot encdir1_snap is created encdir1_snap_clone1 +In this current state, encdir1, encdir1_snap and encdir1_snap_clone1 are unlocked +and file names and data is accessible as expected in each state. If you perform a +lock on any of the three, all three will become locked. + +.. note:: + + Snapshot names are not encrypted. diff --git a/doc/dev/cephfs-fscrypt.rst b/doc/dev/cephfs-fscrypt.rst new file mode 100644 index 00000000000..6d849e65af8 --- /dev/null +++ b/doc/dev/cephfs-fscrypt.rst @@ -0,0 +1,102 @@ +CephFS Fscrypt +================ + +Fscrypt is an encryption implementation at the file system level. This file +system encryption allows for encrypting on a per directory level. This allows +for file systems to have encrypted and regular non-encrypted portions. +Fscrypt encryption encrypts file names and data contents. + +This page will cover important key concepts that are part of our cephfs +implementation. If you would like to see the full kernel specification +please visit: https://docs.kernel.org/filesystems/fscrypt.html + +Key Derivation Process +------------------------- +The master key is the cornerstone to derive all keys within an fscrypt context. + +When an fscrypt policy is applied to an empty directory, a per-directory key +is generated using the master key and a randomly generated nonce. This +per-directory key will then be used to encrypt names of directories, +filenames, and symlinks. Each name within a directory is encrypted with the same +per-directory key to allow for faster metadata operations. + +When each file gets created, it will use the parent directory key to generate +a per-file key. This per-file key will be used to encrypt the data contents +of a file. The data contents of a file are broken up into fscrypt blocks in +the size of 4K each. These block will each be encrypted a on a per-block +basis that is derived from the per-file key. + +Generating filenames +------------------- +When a new inode is created, the name provided is encrypted using the +per-directory key. The plaintext file name will be encrypted. This cipher +text is then converted to a base64 format. This is to ensure that there are no +illegal characters in the directory name (dname). If the length of the base64 +encoded name is small enough to fit within a dname entry it will be stored. If +the encoded text is longer than ``NAME_MAX``, the cipher text will be stored in +the ``alternate_name`` field. This cipher text will then be truncated to a smaller +size to be base64 encoded and stored in the dname. + +Per-block encryption keys +------------------- +When data blocks are written to a file each block will be written in fscrypt +block sized chunks (4096 bytes) with a unique key. Each per-block key will be +derived from the per-file key+block_num. This means that each encrypted block +written will have a unique key. + +Exploring the write path +------------------------ +FSCrypt stores data in a granularity of an fscrypt block size of 4096 bytes. +When a file is written data it is split into 4K chunks and then encrypted into a +4K encrypted block. If a write is smaller than 4K in size, it will be +zero-padded up to 4K and then encrypted. + +The inode holds two values for sizes of encrypted files: + +* Logical size represents the plaintext unencrypted version of the data. This + is stored in a virtual extended attribute named ``ceph.fscrypt.file``. + +* Real size is the encrypted size, which is the 4K padded, that is stored on the + osds. + +When modifying existing files and blocks, a read modify write workload may be +needed. For instance, if a single block needs to be partially updated as, shown +in Figure 1, then a rmw workload is needed. First the block is read, then +decrypted based on the key+blocknum, then new data is merged with the plaintext +version and then encrypted before being written out to the osds. + +.. image:: cephfs_fscrypt_rmw_partially_aligned.svg +Figure 1 + +To determine if a rmw is needed the offset and len of write is analyzed. + +* If an offset is not aligned to an fscrypt block a rmw described above will be + needed. This checks to see if a read is needed for the start of a write. + +* If the offset+len is not aligned to an fscrypt block rmw will be needed here. + This checks to see if a read is needed for the end of a write. + +* If more than two blocks are part of a write, any adjacent blocks will not + require a read. This is because a complete overwrite of an fscrypt block will + be performed and any previous data read will not be needed. This behavior is + shown in Figure 2. In this case, only blocks 3 and 5 will need to be read. + +.. image:: cephfs_fscrypt_rmw_3blocks.svg +Figure 2 + +Space Amplification +--------------------- +In nearly all cases, using encryption will cause space amplification. Any data +sets that aren’t uniformly aligned to fscrypt block boundaries will have this. +The ``max_size`` quota is based off this amplified real size. + +Truncates +------------------------- +In cases where a truncate call is not fscrypt block aligned, it will require +rmw on the end block. Since a truncate call is handled by the mds, this rmw +operation is partially handled by the mds. First, the client reads the last block. +Then, as shown in Figure 3, the client requests a truncate (1), mds then does the +write directly to the osds(2,3) before returning status back to the client(4). + +.. image:: cephfs_fscrypt_truncate_handshake.svg +Figure 3 diff --git a/doc/dev/cephfs_fscrypt_rmw_3blocks.svg b/doc/dev/cephfs_fscrypt_rmw_3blocks.svg new file mode 100644 index 00000000000..c44f304b319 --- /dev/null +++ b/doc/dev/cephfs_fscrypt_rmw_3blocks.svg @@ -0,0 +1,4 @@ + + + +
1
2
3
5%3CmxGraphModel%3E%3Croot%3E%3CmxCell%20id%3D%220%22%2F%3E%3CmxCell%20id%3D%221%22%20parent%3D%220%22%2F%3E%3CmxCell%20id%3D%222%22%20value%3D%22%22%20style%3D%22rounded%3D0%3BwhiteSpace%3Dwrap%3Bhtml%3D1%3BfillColor%3D%23dae8fc%3BstrokeColor%3D%236c8ebf%3BstrokeWidth%3D3%3B%22%20vertex%3D%221%22%20parent%3D%221%22%3E%3CmxGeometry%20x%3D%22185%22%20y%3D%22195%22%20width%3D%22480%22%20height%3D%2280%22%20as%3D%22geometry%22%2F%3E%3C%2FmxCell%3E%3CmxCell%20id%3D%223%22%20value%3D%22%22%20style%3D%22rounded%3D0%3BwhiteSpace%3Dwrap%3Bhtml%3D1%3BfillColor%3D%23dae8fc%3BstrokeColor%3D%236c8ebf%3BstrokeWidth%3D3%3B%22%20vertex%3D%221%22%20parent%3D%221%22%3E%3CmxGeometry%20x%3D%22185%22%20y%3D%22195%22%20width%3D%2280%22%20height%3D%2280%22%20as%3D%22geometry%22%2F%3E%3C%2FmxCell%3E%3CmxCell%20id%3D%224%22%20value%3D%22%22%20style%3D%22rounded%3D0%3BwhiteSpace%3Dwrap%3Bhtml%3D1%3BfillColor%3D%23dae8fc%3BstrokeColor%3D%236c8ebf%3BstrokeWidth%3D3%3B%22%20vertex%3D%221%22%20parent%3D%221%22%3E%3CmxGeometry%20x%3D%22265%22%20y%3D%22195%22%20width%3D%2280%22%20height%3D%2280%22%20as%3D%22geometry%22%2F%3E%3C%2FmxCell%3E%3CmxCell%20id%3D%225%22%20value%3D%22%22%20style%3D%22rounded%3D0%3BwhiteSpace%3Dwrap%3Bhtml%3D1%3BfillColor%3D%23dae8fc%3BstrokeColor%3D%236c8ebf%3BstrokeWidth%3D3%3B%22%20vertex%3D%221%22%20parent%3D%221%22%3E%3CmxGeometry%20x%3D%22345%22%20y%3D%22195%22%20width%3D%2280%22%20height%3D%2280%22%20as%3D%22geometry%22%2F%3E%3C%2FmxCell%3E%3CmxCell%20id%3D%226%22%20value%3D%22%22%20style%3D%22rounded%3D0%3BwhiteSpace%3Dwrap%3Bhtml%3D1%3BfillColor%3D%23dae8fc%3BstrokeColor%3D%236c8ebf%3BstrokeWidth%3D3%3B%22%20vertex%3D%221%22%20parent%3D%221%22%3E%3CmxGeometry%20x%3D%22425%22%20y%3D%22195%22%20width%3D%2280%22%20height%3D%2280%22%20as%3D%22geometry%22%2F%3E%3C%2FmxCell%3E%3CmxCell%20id%3D%227%22%20value%3D%22%22%20style%3D%22rounded%3D0%3BwhiteSpace%3Dwrap%3Bhtml%3D1%3BfillColor%3D%23dae8fc%3BstrokeColor%3D%236c8ebf%3BstrokeWidth%3D3%3B%22%20vertex%3D%221%22%20parent%3D%221%22%3E%3CmxGeometry%20x%3D%22505%22%20y%3D%22195%22%20width%3D%2280%22%20height%3D%2280%22%20as%3D%22geometry%22%2F%3E%3C%2FmxCell%3E%3CmxCell%20id%3D%228%22%20value%3D%22%22%20style%3D%22shape%3DcurlyBracket%3BwhiteSpace%3Dwrap%3Bhtml%3D1%3Brounded%3D1%3BflipH%3D1%3BlabelPosition%3Dright%3BverticalLabelPosition%3Dmiddle%3Balign%3Dleft%3BverticalAlign%3Dmiddle%3Brotation%3D-90%3B%22%20vertex%3D%221%22%20parent%3D%221%22%3E%3CmxGeometry%20x%3D%22405%22%20y%3D%22-50%22%20width%3D%2240%22%20height%3D%22390%22%20as%3D%22geometry%22%2F%3E%3C%2FmxCell%3E%3CmxCell%20id%3D%229%22%20value%3D%22foo%22%20style%3D%22text%3Bhtml%3D1%3Balign%3Dcenter%3BverticalAlign%3Dmiddle%3BwhiteSpace%3Dwrap%3Brounded%3D0%3BfontSize%3D18%3B%22%20vertex%3D%221%22%20parent%3D%221%22%3E%3CmxGeometry%20x%3D%22395%22%20y%3D%2275%22%20width%3D%2260%22%20height%3D%2230%22%20as%3D%22geometry%22%2F%3E%3C%2FmxCell%3E%3CmxCell%20id%3D%2210%22%20value%3D%22%22%20style%3D%22rounded%3D0%3BwhiteSpace%3Dwrap%3Bhtml%3D1%3BfillColor%3D%23e1d5e7%3BstrokeColor%3D%239673a6%3BstrokeWidth%3D3%3B%22%20vertex%3D%221%22%20parent%3D%221%22%3E%3CmxGeometry%20x%3D%2274%22%20y%3D%22356%22%20width%3D%2280%22%20height%3D%2280%22%20as%3D%22geometry%22%2F%3E%3C%2FmxCell%3E%3CmxCell%20id%3D%2211%22%20value%3D%22%22%20style%3D%22shape%3DflexArrow%3BendArrow%3Dclassic%3Bhtml%3D1%3Brounded%3D0%3B%22%20edge%3D%221%22%20parent%3D%221%22%3E%3CmxGeometry%20width%3D%2250%22%20height%3D%2250%22%20relative%3D%221%22%20as%3D%22geometry%22%3E%3CmxPoint%20x%3D%22171.5%22%20y%3D%22395.5%22%20as%3D%22sourcePoint%22%2F%3E%3CmxPoint%20x%3D%22266.5%22%20y%3D%22395.5%22%20as%3D%22targetPoint%22%2F%3E%3C%2FmxGeometry%3E%3C%2FmxCell%3E%3CmxCell%20id%3D%2212%22%20value%3D%22%22%20style%3D%22rounded%3D0%3BwhiteSpace%3Dwrap%3Bhtml%3D1%3BfillColor%3D%23ffe6cc%3BstrokeColor%3D%23d79b00%3BstrokeWidth%3D3%3B%22%20vertex%3D%221%22%20parent%3D%221%22%3E%3CmxGeometry%20x%3D%22284%22%20y%3D%22356%22%20width%3D%2280%22%20height%3D%2280%22%20as%3D%22geometry%22%2F%3E%3C%2FmxCell%3E%3CmxCell%20id%3D%2213%22%20value%3D%22decrypt%22%20style%3D%22text%3Bhtml%3D1%3Balign%3Dcenter%3BverticalAlign%3Dmiddle%3BwhiteSpace%3Dwrap%3Brounded%3D0%3BfontSize%3D17%3B%22%20vertex%3D%221%22%20parent%3D%221%22%3E%3CmxGeometry%20x%3D%22189%22%20y%3D%22350%22%20width%3D%2260%22%20height%3D%2230%22%20as%3D%22geometry%22%2F%3E%3C%2FmxCell%3E%3CmxCell%20id%3D%2214%22%20value%3D%22%22%20style%3D%22shape%3DflexArrow%3BendArrow%3Dclassic%3Bhtml%3D1%3Brounded%3D0%3B%22%20edge%3D%221%22%20parent%3D%221%22%3E%3CmxGeometry%20width%3D%2250%22%20height%3D%2250%22%20relative%3D%221%22%20as%3D%22geometry%22%3E%3CmxPoint%20x%3D%22379%22%20y%3D%22398.5%22%20as%3D%22sourcePoint%22%2F%3E%3CmxPoint%20x%3D%22474%22%20y%3D%22398.5%22%20as%3D%22targetPoint%22%2F%3E%3C%2FmxGeometry%3E%3C%2FmxCell%3E%3CmxCell%20id%3D%2215%22%20value%3D%22%22%20style%3D%22rounded%3D0%3BwhiteSpace%3Dwrap%3Bhtml%3D1%3BstrokeWidth%3D3%3B%22%20vertex%3D%221%22%20parent%3D%221%22%3E%3CmxGeometry%20x%3D%22491.5%22%20y%3D%22359%22%20width%3D%2280%22%20height%3D%2280%22%20as%3D%22geometry%22%2F%3E%3C%2FmxCell%3E%3CmxCell%20id%3D%2216%22%20value%3D%22copy%22%20style%3D%22text%3Bhtml%3D1%3Balign%3Dcenter%3BverticalAlign%3Dmiddle%3BwhiteSpace%3Dwrap%3Brounded%3D0%3BfontSize%3D17%3B%22%20vertex%3D%221%22%20parent%3D%221%22%3E%3CmxGeometry%20x%3D%22396.5%22%20y%3D%22353%22%20width%3D%2260%22%20height%3D%2230%22%20as%3D%22geometry%22%2F%3E%3C%2FmxCell%3E%3CmxCell%20id%3D%2217%22%20value%3D%22%22%20style%3D%22rounded%3D0%3BwhiteSpace%3Dwrap%3Bhtml%3D1%3BstrokeWidth%3D3%3BfillColor%3D%23d5e8d4%3BstrokeColor%3D%2382b366%3B%22%20vertex%3D%221%22%20parent%3D%221%22%3E%3CmxGeometry%20x%3D%22491.5%22%20y%3D%22359%22%20width%3D%2280%22%20height%3D%2240%22%20as%3D%22geometry%22%2F%3E%3C%2FmxCell%3E%3CmxCell%20id%3D%2218%22%20value%3D%22%22%20style%3D%22shape%3DflexArrow%3BendArrow%3Dclassic%3Bhtml%3D1%3Brounded%3D0%3B%22%20edge%3D%221%22%20parent%3D%221%22%3E%3CmxGeometry%20width%3D%2250%22%20height%3D%2250%22%20relative%3D%221%22%20as%3D%22geometry%22%3E%3CmxPoint%20x%3D%22584%22%20y%3D%22398.5%22%20as%3D%22sourcePoint%22%2F%3E%3CmxPoint%20x%3D%22679%22%20y%3D%22398.5%22%20as%3D%22targetPoint%22%2F%3E%3C%2FmxGeometry%3E%3C%2FmxCell%3E%3CmxCell%20id%3D%2219%22%20value%3D%22%22%20style%3D%22rounded%3D0%3BwhiteSpace%3Dwrap%3Bhtml%3D1%3BfillColor%3D%23f8cecc%3BstrokeColor%3D%23b85450%3BstrokeWidth%3D3%3B%22%20vertex%3D%221%22%20parent%3D%221%22%3E%3CmxGeometry%20x%3D%22696.5%22%20y%3D%22359%22%20width%3D%2280%22%20height%3D%2280%22%20as%3D%22geometry%22%2F%3E%3C%2FmxCell%3E%3CmxCell%20id%3D%2220%22%20value%3D%22encrypt%22%20style%3D%22text%3Bhtml%3D1%3Balign%3Dcenter%3BverticalAlign%3Dmiddle%3BwhiteSpace%3Dwrap%3Brounded%3D0%3BfontSize%3D17%3B%22%20vertex%3D%221%22%20parent%3D%221%22%3E%3CmxGeometry%20x%3D%22601.5%22%20y%3D%22353%22%20width%3D%2260%22%20height%3D%2230%22%20as%3D%22geometry%22%2F%3E%3C%2FmxCell%3E%3CmxCell%20id%3D%2221%22%20value%3D%22%22%20style%3D%22rounded%3D0%3BwhiteSpace%3Dwrap%3Bhtml%3D1%3BfillColor%3D%23e1d5e7%3BstrokeColor%3D%239673a6%3BstrokeWidth%3D3%3B%22%20vertex%3D%221%22%20parent%3D%221%22%3E%3CmxGeometry%20x%3D%22425%22%20y%3D%22195%22%20width%3D%2280%22%20height%3D%2280%22%20as%3D%22geometry%22%2F%3E%3C%2FmxCell%3E%3C%2Froot%3E%3C%2FmxGraphModel%3E
foo
modify offset 10K-18K of 24K file
4
6
3
5
write(10240, 8192, buf)
 \ No newline at end of file diff --git a/doc/dev/cephfs_fscrypt_rmw_partially_aligned.svg b/doc/dev/cephfs_fscrypt_rmw_partially_aligned.svg new file mode 100644 index 00000000000..949b4229e34 --- /dev/null +++ b/doc/dev/cephfs_fscrypt_rmw_partially_aligned.svg @@ -0,0 +1,4 @@ + + + +
foo
modify offset 12K-14K of 24K file
decrypt
copy
encrypt
 \ No newline at end of file diff --git a/doc/dev/cephfs_fscrypt_truncate_handshake.svg b/doc/dev/cephfs_fscrypt_truncate_handshake.svg new file mode 100644 index 00000000000..0e174fd5298 --- /dev/null +++ b/doc/dev/cephfs_fscrypt_truncate_handshake.svg @@ -0,0 +1,4 @@ + + + +
MDS
FSCrypt enabled client
Client
OSD
(1)
(2)
(3)
Ack
(4)
Ack
truncate(size, enc_data)
write(inode, offset, len, enc_data)
 \ No newline at end of file -- 2.47.3