From 45a1473a1540e966ad01a0eb81ef607845642caa Mon Sep 17 00:00:00 2001 From: Zac Dover Date: Sun, 10 Jul 2022 02:10:31 +1000 Subject: [PATCH] doc/dev: edit delayed-delete.rst This PR improves the English in the "CephFS Delayed Deletion" chapter of the Ceph Internals Guide (which is stored in the doc/dev/ directory). There was no pressing need to rewrite this. I just saw that it could be tightened up, and I had the fifteen minutes I needed to do it. Co-author: Anthony D'Atri Signed-off-by: Zac Dover (cherry picked from commit c186c5ec6cb2ea1999cb14500aaa64d6aa72dddd) --- doc/dev/delayed-delete.rst | 15 ++++++++------- 1 file changed, 8 insertions(+), 7 deletions(-) diff --git a/doc/dev/delayed-delete.rst b/doc/dev/delayed-delete.rst index bf5f65a460893..31f3e6b9727fe 100644 --- a/doc/dev/delayed-delete.rst +++ b/doc/dev/delayed-delete.rst @@ -2,11 +2,12 @@ CephFS delayed deletion ========================= -When you delete a file, the data is not immediately removed. Each -object in the file needs to be removed independently, and sending -``size_of_file / stripe_size * replication_count`` messages would slow -the client down too much, and use a too much of the clients -bandwidth. Additionally, snapshots may mean some objects should not be -deleted. +The deletion of a file does not immediately remove its data. Each of the file's +underlying objects must be removed independently. If these objects were removed +immediately, the client would have to send ``size_of_file / stripe_size * +replication_count`` messages. This would consume significant bandwith and would +slow the client unacceptably. If snapshots exist, their existence can prevent +the deletion of objects associated with them. -Instead, the file is marked as deleted on the MDS, and deleted lazily. +In these cases, such files are (1) marked as deleted on the MDS and (2) deleted +lazily. -- 2.39.5