From: Edward Shishkin <email@example.com> To: ReiserFS development mailing list <firstname.lastname@example.org>, linux-kernel <email@example.com> Cc: Pavel Machek <firstname.lastname@example.org> Subject: Reiser5 Logical Volume Management - Updates Date: Sun, 22 Nov 2020 21:24:30 +0100 Message-ID: <email@example.com> (raw) Reiser5 Logical Volume Management - Updates I am happy to inform, that Logical Volumes stuff has become more stable. Also we introduce the following changes, which make logical volumes administration more flexible and simple: 1. No balancing by default Now all volume operations except brick removal don't invoke balancing by default. Instead, they mark volume as "unbalanced". To complete any operation with balancing specify option -B (--with-balance), or run volume.reiser4(8) utility with the option -b (--balance) later. This allows to speed up more than one operations over logical volume being performed at once. For example, if you want to add more than one brick to your volume at once, first add all the bricks, then run balancing. There is no need to balance a volume between the addition operations. 2. Removal completion Operation of brick removal always includes balancing procedure as its part. This procedure moves out all data block from the brick to be removed to remaining bricks of the volume. Thus, brick removal is usually a long operation, which may be interrupted for various reasons In such cases the volume is automatically marked with an "incomplete removal" flag. It is not allowed to perform essential volume operations on a volume marked as "with incomplete removal": first, user should complete removal by running volume.reiser4 utility with option -R (--finish-removal). Otherwise, the operation will return error (-EBUSY). There is no other restrictions: you are allowed to add a brick to unbalanced volume, and even remove a brick from an unbalanced volume (assuming it is not incomplete removal). Comment. "--finish-removal" is a temporary option. In the future the file system will detect incomplete removal and automatically perform removal completion by itself. 3. Balancing is always defined Operation of volume balancing (regardless of its balanced status) is always defined, and can be launched at any moment. If the volume is balanced, then the balancing procedure just scans the volume without any useful work. It is allowed to run more than one balancing threads on the same volume, however currently it will be inefficient: other threads will be always going after the single leader without doing useful work. Efficient volume balancing by many threads (true parallelism) is not a trivial task. We estimate its complexity as 2/5. 4. Restore regular distribution on the volume Custom (defined by user) file migration can break fairness of data distribution among the bricks. To restore regular (fair) distribution on the volume, run volume.reiser4 utility with the option -S (--restore-regular). It launches a balancing procedure, which performs mandatory data migration of all files (including the ones marked as "immobile") in accordance with regular distribution policy on the volume. Moreover, when the balancing procedure encounters a file marked as "immobile", its "immobile" flag is cleared up. 5. How to test The new functionality is available starting with the kernel patch reiser4-for-linux-5.10-rc3 and reiser4progs-2.0.4 (Software Framework Release number of both is 5.1.3). Links for download: https://sourceforge.net/projects/reiser4/files/v5-unstable/kernel/ https://sourceforge.net/projects/reiser4/files/v5-unstable/progs/ Find updated documentation on getting started with logical volumes: https://reiser4.wiki.kernel.org/index.php/Logical_Volumes_Administration https://reiser4.wiki.kernel.org/index.php/Proxy_Device_Administration https://reiser4.wiki.kernel.org/index.php/Transparent_File_Migration Also see manual pages for volume.reiser4(8) utility.
reply index Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
LKML Archive on lore.kernel.org Archives are clonable: git clone --mirror https://lore.kernel.org/lkml/0 lkml/git/0.git git clone --mirror https://lore.kernel.org/lkml/1 lkml/git/1.git git clone --mirror https://lore.kernel.org/lkml/2 lkml/git/2.git git clone --mirror https://lore.kernel.org/lkml/3 lkml/git/3.git git clone --mirror https://lore.kernel.org/lkml/4 lkml/git/4.git git clone --mirror https://lore.kernel.org/lkml/5 lkml/git/5.git git clone --mirror https://lore.kernel.org/lkml/6 lkml/git/6.git git clone --mirror https://lore.kernel.org/lkml/7 lkml/git/7.git git clone --mirror https://lore.kernel.org/lkml/8 lkml/git/8.git git clone --mirror https://lore.kernel.org/lkml/9 lkml/git/9.git # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V2 lkml lkml/ https://lore.kernel.org/lkml \ email@example.com public-inbox-index lkml Example config snippet for mirrors Newsgroup available over NNTP: nntp://nntp.lore.kernel.org/org.kernel.vger.linux-kernel AGPL code for this site: git clone https://public-inbox.org/public-inbox.git