lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date:	Mon, 08 Feb 2010 16:28:02 +0300
From:	Dmitry Monakhov <dmonakhov@...nvz.org>
To:	linux-ext4@...r.kernel.org
Cc:	Jan Kara <jack@...e.cz>, Dmitry Monakhov <dmonakhov@...nvz.org>
Subject: [PATCH 00/11] [RFC] Introduce subtree quota support This patch set
 introduce subtree and subtree-quota support for ext4

A subtree of a directory tree T is a tree consisting of a directory
(the subtree root) in T and all of its descendants in T.

Subtree assumptions:
* Each inode has subtree id.
* Subtree id is inherent from parent directory
* Inode can not belongs to different subtree

Subtree with id == 0 has special meaning. It may contains roots of
other subtrees (this feature is used for cross subtree renames)
This feature has much in common with XFS project_id.

In fact subtrees support may be implemented in generic vfs layer (may be
sometimes it will be)

There are many usecases for such subtrees

1) Choroot environment or Containers on common file-system
   administrator creates a subtree,and setup quota
   #mkdir chroot-env
   #chattr -Q ${subtree_id} chroot-env
   #tar jxf /tmp/fedora-x86_64.tar.bz2 -C chroot-env
   #### as soon as subtree id inherented from parent untared content
   #### automatically belongs to ${subtree_id}
   #quotactl --type=subtree --id=${subtree_id} --bsoft=1000000 --bhard=1000000
   ###
   #chroot chroot-env /bin/bash
2) NFS quota on server side
   Administrator perform exactly the same stages, but instead of chroot
   hi just export result subtree to nfs server


One may imagine it's own usecase.

Usually we already have some content which we want to see as subtree
In this case we have to in-depth traverse it from the subtree root.
add_to_subtree(dir, subtree_id) /* in-depth  tree traversal */
{
	while(de = getdents(dir)) {
	     if (IS_DIR(de))
		    add_to_subtree(de, subtree_id)
             else
	            set_subtree_id(de, subtree);
       }
       set_subtree_id(de, subtree);
}
It is possible to manipulate subtree content

For example we have following hierarchy
/root/subtree-1/a/b/c/d/e/f/g
/root/subtree-2/dir/
want rename /root/subtree-1/a to /root/subtree-2/dir/AA
first we have to move "a" to default tree "root"
 #rename /root/subtree-1/a /root/a-1
Then we have assign to default subtree. Do it in width traverse order
Because otherwise this result in subtree assumptions violation.
 #walk_in_width(/root/AA, 0 /* default subtree */)
Then  assign target subtree_id
 #walk_in_depth(/root/AA, 2)
Ok now all content from /root/a-1 belongs to subtree_id == 2 so it is possible
rename it in to target place
 #rename /root/a-1 /root/subtree-2/dir/AA

If you still reading this then i'll give comment about patch set organization

## Patch set prepared against ext4.git:next
## Following two patches already acceped by Jan Kara,
## but not yet in ext4 tree
##
ext4-mount-flags-manipulation-cleanup.patch
ext4-trivial-quota-cleanup.patch
## Following for patches perform necessety generic quota changes
## in order to new quota type
quota-sb_quota-state-flags-cleanup.patch
quota-generalize-quota-transfer-interface.patch
quota-introduce-get_id-callback.patch
quota-add-generic-subtree-quota-support.patch
## ext4 is so feature rich so there is no enouth space to store
## all it's mount flags
ext4-enlarge-mount-option-field.patch
## subtree support for ext4
ext4-introduce-subtree-logic.patch
ext4-subtree-add-kconfig-options.patch
ext4-add-subtree-support.patch
## subtree quota support for ext3
ext4-add-subtree-quota-support.patch
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ