diff for duplicates of <20101206142743.GA2556@localhost.localdomain> diff --git a/a/1.txt b/N1/1.txt index 1bcd11a..85b2c37 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -3,257 +3,172 @@ On Sat, Dec 04, 2010 at 01:58:07PM -0800, Mike Fedyk wrote: > > On Wed, Dec 01, 2010 at 09:21:36AM -0500, Josef Bacik wrote: > >> Hello, > >> -> >> Various people have complained about how BTRFS deals with subvolum= -es recently, -> >> specifically the fact that they all have the same inode number, an= -d there's no -> >> discrete seperation from one subvolume to another. =A0Christoph as= -ked that I lay -> >> out a basic design document of how we want subvolumes to work so w= -e can hash -> >> everything out now, fix what is broken, and then move forward with= - a design that -> >> everybody is more or less happy with. =A0I apologize in advance fo= -r how freaking -> >> long this email is going to be. =A0I assume that most people are g= -enerally -> >> familiar with how BTRFS works, so I'm not going to bother explaini= -ng in great +> >> Various people have complained about how BTRFS deals with subvolumes recently, +> >> specifically the fact that they all have the same inode number, and there's no +> >> discrete seperation from one subvolume to another. Christoph asked that I lay +> >> out a basic design document of how we want subvolumes to work so we can hash +> >> everything out now, fix what is broken, and then move forward with a design that +> >> everybody is more or less happy with. I apologize in advance for how freaking +> >> long this email is going to be. I assume that most people are generally +> >> familiar with how BTRFS works, so I'm not going to bother explaining in great > >> detail some stuff. > >> -> >> =3D=3D=3D What are subvolumes? =3D=3D=3D +> >> === What are subvolumes? === > >> -> >> They are just another tree. =A0In BTRFS we have various b-trees to= - describe the -> >> filesystem. =A0A few of them are filesystem wide, such as the exte= -nt tree, chunk -> >> tree, root tree etc. =A0The tree's that hold the actual filesystem= - data, that is -> >> inodes and such, are kept in their own b-tree. =A0This is how subv= -olumes and -> >> snapshots appear on disk, they are simply new b-trees with all of = -the file data +> >> They are just another tree. In BTRFS we have various b-trees to describe the +> >> filesystem. A few of them are filesystem wide, such as the extent tree, chunk +> >> tree, root tree etc. The tree's that hold the actual filesystem data, that is +> >> inodes and such, are kept in their own b-tree. This is how subvolumes and +> >> snapshots appear on disk, they are simply new b-trees with all of the file data > >> contained within them. > >> -> >> =3D=3D=3D What do subvolumes look like? =3D=3D=3D +> >> === What do subvolumes look like? === > >> -> >> All the user sees are directories. =A0They act like any other dire= -ctory acts, with +> >> All the user sees are directories. They act like any other directory acts, with > >> a few exceptions > >> -> >> 1) You cannot hardlink between subvolumes. =A0This is because subv= -olumes have -> >> their own inode numbers and such, think of them as seperate mounts= - in this case, -> >> you cannot hardlink between two mounts because the link needs to p= -oint to the -> >> same on disk inode, which is impossible between two different file= -systems. =A0The -> >> same is true for subvolumes, they have their own trees with their = -own inodes and +> >> 1) You cannot hardlink between subvolumes. This is because subvolumes have +> >> their own inode numbers and such, think of them as seperate mounts in this case, +> >> you cannot hardlink between two mounts because the link needs to point to the +> >> same on disk inode, which is impossible between two different filesystems. The +> >> same is true for subvolumes, they have their own trees with their own inodes and > >> inode numbers, so it's impossible to hardlink between them. > >> -> >> 1a) In case it wasn't clear from above, each subvolume has their o= -wn inode -> >> numbers, so you can have the same inode numbers used between two d= -ifferent +> >> 1a) In case it wasn't clear from above, each subvolume has their own inode +> >> numbers, so you can have the same inode numbers used between two different > >> subvolumes, since they are two different trees. > >> -> >> 2) Obviously you can't just rm -rf subvolumes. =A0Because they are= - roots there's -> >> extra metadata to keep track of them, so you have to use one of ou= -r ioctls to +> >> 2) Obviously you can't just rm -rf subvolumes. Because they are roots there's +> >> extra metadata to keep track of them, so you have to use one of our ioctls to > >> delete subvolumes/snapshots. > >> > >> But permissions and everything else they are the same. > >> -> >> There is one tricky thing. =A0When you create a subvolume, the dir= -ectory inode -> >> that is created in the parent subvolume has the inode number of 25= -6. =A0So if you -> >> have a bunch of subvolumes in the same parent subvolume, you are g= -oing to have a -> >> bunch of directories with the inode number of 256. =A0This is so w= -hen users cd -> >> into a subvolume we can know its a subvolume and do all the normal= - voodoo to -> >> start looking in the subvolumes tree instead of the parent subvolu= -mes tree. +> >> There is one tricky thing. When you create a subvolume, the directory inode +> >> that is created in the parent subvolume has the inode number of 256. So if you +> >> have a bunch of subvolumes in the same parent subvolume, you are going to have a +> >> bunch of directories with the inode number of 256. This is so when users cd +> >> into a subvolume we can know its a subvolume and do all the normal voodoo to +> >> start looking in the subvolumes tree instead of the parent subvolumes tree. > >> -> >> This is where things go a bit sideways. =A0We had serious problems= - with NFS, but -> >> thankfully NFS gives us a bunch of hooks to get around these probl= -ems. -> >> CIFS/Samba do not, so we will have problems there, not to mention = -any other +> >> This is where things go a bit sideways. We had serious problems with NFS, but +> >> thankfully NFS gives us a bunch of hooks to get around these problems. +> >> CIFS/Samba do not, so we will have problems there, not to mention any other > >> userspace application that looks at inode numbers. > >> -> >> =3D=3D=3D How do we want subvolumes to work from a user perspectiv= -e? =3D=3D=3D +> >> === How do we want subvolumes to work from a user perspective? === > >> -> >> 1) Users need to be able to create their own subvolumes. =A0The pe= -rmission -> >> semantics will be absolutely the same as creating directories, so = -I don't think -> >> this is too tricky. =A0We want this because you can only take snap= -shots of -> >> subvolumes, and so it is important that users be able to create th= -eir own +> >> 1) Users need to be able to create their own subvolumes. The permission +> >> semantics will be absolutely the same as creating directories, so I don't think +> >> this is too tricky. We want this because you can only take snapshots of +> >> subvolumes, and so it is important that users be able to create their own > >> discrete snapshottable targets. > >> -> >> 2) Users need to be able to snapshot their subvolumes. =A0This is = -basically the +> >> 2) Users need to be able to snapshot their subvolumes. This is basically the > >> same as #1, but it bears repeating. > >> -> >> 3) Subvolumes shouldn't need to be specifically mounted. =A0This i= -s also -> >> important, we don't want users to have to go around mounting their= - subvolumes up -> >> manually one-by-one. =A0Today users just cd into subvolumes and it= - works, just +> >> 3) Subvolumes shouldn't need to be specifically mounted. This is also +> >> important, we don't want users to have to go around mounting their subvolumes up +> >> manually one-by-one. Today users just cd into subvolumes and it works, just > >> like cd'ing into a directory. > >> -> >> =3D=3D=3D Quotas =3D=3D=3D +> >> === Quotas === > >> -> >> This is a huge topic in and of itself, but Christoph mentioned wan= -ting to have -> >> an idea of what we wanted to do with it, so I'm putting it here. =A0= -There are +> >> This is a huge topic in and of itself, but Christoph mentioned wanting to have +> >> an idea of what we wanted to do with it, so I'm putting it here. There are > >> really 2 things here > >> -> >> 1) Limiting the size of subvolumes. =A0This is really easy for us,= - just create a -> >> subvolume and at creation time set a maximum size it can grow to a= -nd not let it -> >> go farther than that. =A0Nice, simple and straightforward. +> >> 1) Limiting the size of subvolumes. This is really easy for us, just create a +> >> subvolume and at creation time set a maximum size it can grow to and not let it +> >> go farther than that. Nice, simple and straightforward. > >> -> >> 2) Normal quotas, via the quota tools. =A0This just comes down to = -how do we want -> >> to charge users, do we want to do it per subvolume, or per filesys= -tem. =A0My vote -> >> is per filesystem. =A0Obviously this will make it tricky with snap= -shots, but I -> >> think if we're just charging the diff's between the original volum= -e and the -> >> snapshot to the user then that will be the easiest for people to u= -nderstand, -> >> rather than making a snapshot all of a sudden count the users curr= -ently used +> >> 2) Normal quotas, via the quota tools. This just comes down to how do we want +> >> to charge users, do we want to do it per subvolume, or per filesystem. My vote +> >> is per filesystem. Obviously this will make it tricky with snapshots, but I +> >> think if we're just charging the diff's between the original volume and the +> >> snapshot to the user then that will be the easiest for people to understand, +> >> rather than making a snapshot all of a sudden count the users currently used > >> quota * 2. > >> -> >> =3D=3D=3D What do we do? =3D=3D=3D +> >> === What do we do? === > >> -> >> This is where I expect to see the most discussion. =A0Here is what= - I want to do +> >> This is where I expect to see the most discussion. Here is what I want to do > >> -> >> 1) Scrap the 256 inode number thing. =A0Instead we'll just put a f= -lag in the inode -> >> to say "Hey, I'm a subvolume" and then we can do all of the approp= -riate magic -> >> that way. =A0This unfortunately will be an incompatible format cha= -nge, but the -> >> sooner we get this adressed the easier it will be in the long run.= - =A0Obviously -> >> when I say format change I mean via the incompat bits we have, so = -old fs's won't +> >> 1) Scrap the 256 inode number thing. Instead we'll just put a flag in the inode +> >> to say "Hey, I'm a subvolume" and then we can do all of the appropriate magic +> >> that way. This unfortunately will be an incompatible format change, but the +> >> sooner we get this adressed the easier it will be in the long run. Obviously +> >> when I say format change I mean via the incompat bits we have, so old fs's won't > >> be broken and such. > >> -> >> 2) Do something like NFS's referral mounts when we cd into a subvo= -lume. =A0Now we -> >> just do dentry trickery, but that doesn't make the boundary betwee= -n subvolumes -> >> clear, so it will confuse people (and samba) when they walk into a= - subvolume and -> >> all of a sudden the inode numbers are the same as in the directory= - behind them. -> >> With doing the referral mount thing, each subvolume appears to be = -its own mount +> >> 2) Do something like NFS's referral mounts when we cd into a subvolume. Now we +> >> just do dentry trickery, but that doesn't make the boundary between subvolumes +> >> clear, so it will confuse people (and samba) when they walk into a subvolume and +> >> all of a sudden the inode numbers are the same as in the directory behind them. +> >> With doing the referral mount thing, each subvolume appears to be its own mount > >> and that way things like NFS and samba will work properly. > >> -> >> I feel like I'm forgetting something here, hopefully somebody will= - point it out. +> >> I feel like I'm forgetting something here, hopefully somebody will point it out. > >> -> >> =3D=3D=3D Conclusion =3D=3D=3D +> >> === Conclusion === > >> -> >> There are definitely some wonky things with subvolumes, but I don'= -t think they -> >> are things that cannot be fixed now. =A0Some of these changes will= - require -> >> incompat format changes, but it's either we fix it now, or later o= -n down the -> >> road when BTRFS starts getting used in production really find out = -how many -> >> things our current scheme breaks and then have to do the changes t= -hen. =A0Thanks, +> >> There are definitely some wonky things with subvolumes, but I don't think they +> >> are things that cannot be fixed now. Some of these changes will require +> >> incompat format changes, but it's either we fix it now, or later on down the +> >> road when BTRFS starts getting used in production really find out how many +> >> things our current scheme breaks and then have to do the changes then. Thanks, > >> > > -> > So now that I've actually looked at everything, it looks like the s= -emantics are +> > So now that I've actually looked at everything, it looks like the semantics are > > all right for subvolumes > > -> > 1) readdir - we return the root id in d_ino, which is unique across= - the fs -> > 2) stat - we return 256 for all subvolumes, because that is their i= -node number -> > 3) dev_t - we setup an anon super for all volumes, so they all get = -their own +> > 1) readdir - we return the root id in d_ino, which is unique across the fs +> > 2) stat - we return 256 for all subvolumes, because that is their inode number +> > 3) dev_t - we setup an anon super for all volumes, so they all get their own > > dev_t, which is set properly for all of their children, see below > > > > [root@test1244 btrfs-test]# stat . -> > =A0File: `.' -> > =A0Size: 20 =A0 =A0 =A0 =A0 =A0 =A0 =A0Blocks: 8 =A0 =A0 =A0 =A0 =A0= -IO Block: 4096 =A0 directory -> > Device: 15h/21d Inode: 256 =A0 =A0 =A0 =A0 Links: 1 -> > Access: (0555/dr-xr-xr-x) =A0Uid: ( =A0 =A00/ =A0 =A0root) =A0 Gid:= - ( =A0 =A00/ =A0 =A0root) +> > File: `.' +> > Size: 20 Blocks: 8 IO Block: 4096 directory +> > Device: 15h/21d Inode: 256 Links: 1 +> > Access: (0555/dr-xr-xr-x) Uid: ( 0/ root) Gid: ( 0/ root) > > Access: 2010-12-03 15:35:41.931679393 -0500 > > Modify: 2010-12-03 15:35:20.405679493 -0500 > > Change: 2010-12-03 15:35:20.405679493 -0500 > > > > [root@test1244 btrfs-test]# stat foo -> > =A0File: `foo' -> > =A0Size: 12 =A0 =A0 =A0 =A0 =A0 =A0 =A0Blocks: 0 =A0 =A0 =A0 =A0 =A0= -IO Block: 4096 =A0 directory -> > Device: 19h/25d Inode: 256 =A0 =A0 =A0 =A0 Links: 1 -> > Access: (0700/drwx------) =A0Uid: ( =A0 =A00/ =A0 =A0root) =A0 Gid:= - ( =A0 =A00/ =A0 =A0root) +> > File: `foo' +> > Size: 12 Blocks: 0 IO Block: 4096 directory +> > Device: 19h/25d Inode: 256 Links: 1 +> > Access: (0700/drwx------) Uid: ( 0/ root) Gid: ( 0/ root) > > Access: 2010-12-03 15:35:17.501679393 -0500 > > Modify: 2010-12-03 15:35:59.150680051 -0500 > > Change: 2010-12-03 15:35:59.150680051 -0500 > > > > [root@test1244 btrfs-test]# stat foo/foobar -> > =A0File: `foo/foobar' -> > =A0Size: 0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Blocks: 0 =A0 =A0 =A0 =A0 =A0= -IO Block: 4096 =A0 regular empty file -> > Device: 19h/25d Inode: 257 =A0 =A0 =A0 =A0 Links: 1 -> > Access: (0644/-rw-r--r--) =A0Uid: ( =A0 =A00/ =A0 =A0root) =A0 Gid:= - ( =A0 =A00/ =A0 =A0root) +> > File: `foo/foobar' +> > Size: 0 Blocks: 0 IO Block: 4096 regular empty file +> > Device: 19h/25d Inode: 257 Links: 1 +> > Access: (0644/-rw-r--r--) Uid: ( 0/ root) Gid: ( 0/ root) > > Access: 2010-12-03 15:35:59.150680051 -0500 > > Modify: 2010-12-03 15:35:59.150680051 -0500 > > Change: 2010-12-03 15:35:59.150680051 -0500 > > -> > So as far as the user is concerned, everything should come out righ= -t. =A0Obviously -> > we had to do the NFS trickery still because as far as VFS is concer= -ned the -> > subvolumes are all on the same mount. =A0So the question is this (a= -nd really this -> > is directed at Christoph and Bruce and anybody else who may care), = -is this good -> > enough, or do we want to have a seperate vfsmount for each subvolum= -e? =A0Thanks, +> > So as far as the user is concerned, everything should come out right. Obviously +> > we had to do the NFS trickery still because as far as VFS is concerned the +> > subvolumes are all on the same mount. So the question is this (and really this +> > is directed at Christoph and Bruce and anybody else who may care), is this good +> > enough, or do we want to have a seperate vfsmount for each subvolume? Thanks, > > ->=20 +> > What are the drawbacks of having a vfsmount for each subvolume? ->=20 -> Why (besides having to code it up) are you trying to avoid doing it t= -hat way? +> +> Why (besides having to code it up) are you trying to avoid doing it that way? It's the having to code it up that way thing, I'm nothing if not lazy. Josef -- -To unsubscribe from this list: send the line "unsubscribe linux-btrfs" = -in +To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html diff --git a/a/content_digest b/N1/content_digest index 9c6c4ca..9f050db 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -19,259 +19,174 @@ "> > On Wed, Dec 01, 2010 at 09:21:36AM -0500, Josef Bacik wrote:\n" "> >> Hello,\n" "> >>\n" - "> >> Various people have complained about how BTRFS deals with subvolum=\n" - "es recently,\n" - "> >> specifically the fact that they all have the same inode number, an=\n" - "d there's no\n" - "> >> discrete seperation from one subvolume to another. =A0Christoph as=\n" - "ked that I lay\n" - "> >> out a basic design document of how we want subvolumes to work so w=\n" - "e can hash\n" - "> >> everything out now, fix what is broken, and then move forward with=\n" - " a design that\n" - "> >> everybody is more or less happy with. =A0I apologize in advance fo=\n" - "r how freaking\n" - "> >> long this email is going to be. =A0I assume that most people are g=\n" - "enerally\n" - "> >> familiar with how BTRFS works, so I'm not going to bother explaini=\n" - "ng in great\n" + "> >> Various people have complained about how BTRFS deals with subvolumes recently,\n" + "> >> specifically the fact that they all have the same inode number, and there's no\n" + "> >> discrete seperation from one subvolume to another. \302\240Christoph asked that I lay\n" + "> >> out a basic design document of how we want subvolumes to work so we can hash\n" + "> >> everything out now, fix what is broken, and then move forward with a design that\n" + "> >> everybody is more or less happy with. \302\240I apologize in advance for how freaking\n" + "> >> long this email is going to be. \302\240I assume that most people are generally\n" + "> >> familiar with how BTRFS works, so I'm not going to bother explaining in great\n" "> >> detail some stuff.\n" "> >>\n" - "> >> =3D=3D=3D What are subvolumes? =3D=3D=3D\n" + "> >> === What are subvolumes? ===\n" "> >>\n" - "> >> They are just another tree. =A0In BTRFS we have various b-trees to=\n" - " describe the\n" - "> >> filesystem. =A0A few of them are filesystem wide, such as the exte=\n" - "nt tree, chunk\n" - "> >> tree, root tree etc. =A0The tree's that hold the actual filesystem=\n" - " data, that is\n" - "> >> inodes and such, are kept in their own b-tree. =A0This is how subv=\n" - "olumes and\n" - "> >> snapshots appear on disk, they are simply new b-trees with all of =\n" - "the file data\n" + "> >> They are just another tree. \302\240In BTRFS we have various b-trees to describe the\n" + "> >> filesystem. \302\240A few of them are filesystem wide, such as the extent tree, chunk\n" + "> >> tree, root tree etc. \302\240The tree's that hold the actual filesystem data, that is\n" + "> >> inodes and such, are kept in their own b-tree. \302\240This is how subvolumes and\n" + "> >> snapshots appear on disk, they are simply new b-trees with all of the file data\n" "> >> contained within them.\n" "> >>\n" - "> >> =3D=3D=3D What do subvolumes look like? =3D=3D=3D\n" + "> >> === What do subvolumes look like? ===\n" "> >>\n" - "> >> All the user sees are directories. =A0They act like any other dire=\n" - "ctory acts, with\n" + "> >> All the user sees are directories. \302\240They act like any other directory acts, with\n" "> >> a few exceptions\n" "> >>\n" - "> >> 1) You cannot hardlink between subvolumes. =A0This is because subv=\n" - "olumes have\n" - "> >> their own inode numbers and such, think of them as seperate mounts=\n" - " in this case,\n" - "> >> you cannot hardlink between two mounts because the link needs to p=\n" - "oint to the\n" - "> >> same on disk inode, which is impossible between two different file=\n" - "systems. =A0The\n" - "> >> same is true for subvolumes, they have their own trees with their =\n" - "own inodes and\n" + "> >> 1) You cannot hardlink between subvolumes. \302\240This is because subvolumes have\n" + "> >> their own inode numbers and such, think of them as seperate mounts in this case,\n" + "> >> you cannot hardlink between two mounts because the link needs to point to the\n" + "> >> same on disk inode, which is impossible between two different filesystems. \302\240The\n" + "> >> same is true for subvolumes, they have their own trees with their own inodes and\n" "> >> inode numbers, so it's impossible to hardlink between them.\n" "> >>\n" - "> >> 1a) In case it wasn't clear from above, each subvolume has their o=\n" - "wn inode\n" - "> >> numbers, so you can have the same inode numbers used between two d=\n" - "ifferent\n" + "> >> 1a) In case it wasn't clear from above, each subvolume has their own inode\n" + "> >> numbers, so you can have the same inode numbers used between two different\n" "> >> subvolumes, since they are two different trees.\n" "> >>\n" - "> >> 2) Obviously you can't just rm -rf subvolumes. =A0Because they are=\n" - " roots there's\n" - "> >> extra metadata to keep track of them, so you have to use one of ou=\n" - "r ioctls to\n" + "> >> 2) Obviously you can't just rm -rf subvolumes. \302\240Because they are roots there's\n" + "> >> extra metadata to keep track of them, so you have to use one of our ioctls to\n" "> >> delete subvolumes/snapshots.\n" "> >>\n" "> >> But permissions and everything else they are the same.\n" "> >>\n" - "> >> There is one tricky thing. =A0When you create a subvolume, the dir=\n" - "ectory inode\n" - "> >> that is created in the parent subvolume has the inode number of 25=\n" - "6. =A0So if you\n" - "> >> have a bunch of subvolumes in the same parent subvolume, you are g=\n" - "oing to have a\n" - "> >> bunch of directories with the inode number of 256. =A0This is so w=\n" - "hen users cd\n" - "> >> into a subvolume we can know its a subvolume and do all the normal=\n" - " voodoo to\n" - "> >> start looking in the subvolumes tree instead of the parent subvolu=\n" - "mes tree.\n" + "> >> There is one tricky thing. \302\240When you create a subvolume, the directory inode\n" + "> >> that is created in the parent subvolume has the inode number of 256. \302\240So if you\n" + "> >> have a bunch of subvolumes in the same parent subvolume, you are going to have a\n" + "> >> bunch of directories with the inode number of 256. \302\240This is so when users cd\n" + "> >> into a subvolume we can know its a subvolume and do all the normal voodoo to\n" + "> >> start looking in the subvolumes tree instead of the parent subvolumes tree.\n" "> >>\n" - "> >> This is where things go a bit sideways. =A0We had serious problems=\n" - " with NFS, but\n" - "> >> thankfully NFS gives us a bunch of hooks to get around these probl=\n" - "ems.\n" - "> >> CIFS/Samba do not, so we will have problems there, not to mention =\n" - "any other\n" + "> >> This is where things go a bit sideways. \302\240We had serious problems with NFS, but\n" + "> >> thankfully NFS gives us a bunch of hooks to get around these problems.\n" + "> >> CIFS/Samba do not, so we will have problems there, not to mention any other\n" "> >> userspace application that looks at inode numbers.\n" "> >>\n" - "> >> =3D=3D=3D How do we want subvolumes to work from a user perspectiv=\n" - "e? =3D=3D=3D\n" + "> >> === How do we want subvolumes to work from a user perspective? ===\n" "> >>\n" - "> >> 1) Users need to be able to create their own subvolumes. =A0The pe=\n" - "rmission\n" - "> >> semantics will be absolutely the same as creating directories, so =\n" - "I don't think\n" - "> >> this is too tricky. =A0We want this because you can only take snap=\n" - "shots of\n" - "> >> subvolumes, and so it is important that users be able to create th=\n" - "eir own\n" + "> >> 1) Users need to be able to create their own subvolumes. \302\240The permission\n" + "> >> semantics will be absolutely the same as creating directories, so I don't think\n" + "> >> this is too tricky. \302\240We want this because you can only take snapshots of\n" + "> >> subvolumes, and so it is important that users be able to create their own\n" "> >> discrete snapshottable targets.\n" "> >>\n" - "> >> 2) Users need to be able to snapshot their subvolumes. =A0This is =\n" - "basically the\n" + "> >> 2) Users need to be able to snapshot their subvolumes. \302\240This is basically the\n" "> >> same as #1, but it bears repeating.\n" "> >>\n" - "> >> 3) Subvolumes shouldn't need to be specifically mounted. =A0This i=\n" - "s also\n" - "> >> important, we don't want users to have to go around mounting their=\n" - " subvolumes up\n" - "> >> manually one-by-one. =A0Today users just cd into subvolumes and it=\n" - " works, just\n" + "> >> 3) Subvolumes shouldn't need to be specifically mounted. \302\240This is also\n" + "> >> important, we don't want users to have to go around mounting their subvolumes up\n" + "> >> manually one-by-one. \302\240Today users just cd into subvolumes and it works, just\n" "> >> like cd'ing into a directory.\n" "> >>\n" - "> >> =3D=3D=3D Quotas =3D=3D=3D\n" + "> >> === Quotas ===\n" "> >>\n" - "> >> This is a huge topic in and of itself, but Christoph mentioned wan=\n" - "ting to have\n" - "> >> an idea of what we wanted to do with it, so I'm putting it here. =A0=\n" - "There are\n" + "> >> This is a huge topic in and of itself, but Christoph mentioned wanting to have\n" + "> >> an idea of what we wanted to do with it, so I'm putting it here. \302\240There are\n" "> >> really 2 things here\n" "> >>\n" - "> >> 1) Limiting the size of subvolumes. =A0This is really easy for us,=\n" - " just create a\n" - "> >> subvolume and at creation time set a maximum size it can grow to a=\n" - "nd not let it\n" - "> >> go farther than that. =A0Nice, simple and straightforward.\n" + "> >> 1) Limiting the size of subvolumes. \302\240This is really easy for us, just create a\n" + "> >> subvolume and at creation time set a maximum size it can grow to and not let it\n" + "> >> go farther than that. \302\240Nice, simple and straightforward.\n" "> >>\n" - "> >> 2) Normal quotas, via the quota tools. =A0This just comes down to =\n" - "how do we want\n" - "> >> to charge users, do we want to do it per subvolume, or per filesys=\n" - "tem. =A0My vote\n" - "> >> is per filesystem. =A0Obviously this will make it tricky with snap=\n" - "shots, but I\n" - "> >> think if we're just charging the diff's between the original volum=\n" - "e and the\n" - "> >> snapshot to the user then that will be the easiest for people to u=\n" - "nderstand,\n" - "> >> rather than making a snapshot all of a sudden count the users curr=\n" - "ently used\n" + "> >> 2) Normal quotas, via the quota tools. \302\240This just comes down to how do we want\n" + "> >> to charge users, do we want to do it per subvolume, or per filesystem. \302\240My vote\n" + "> >> is per filesystem. \302\240Obviously this will make it tricky with snapshots, but I\n" + "> >> think if we're just charging the diff's between the original volume and the\n" + "> >> snapshot to the user then that will be the easiest for people to understand,\n" + "> >> rather than making a snapshot all of a sudden count the users currently used\n" "> >> quota * 2.\n" "> >>\n" - "> >> =3D=3D=3D What do we do? =3D=3D=3D\n" + "> >> === What do we do? ===\n" "> >>\n" - "> >> This is where I expect to see the most discussion. =A0Here is what=\n" - " I want to do\n" + "> >> This is where I expect to see the most discussion. \302\240Here is what I want to do\n" "> >>\n" - "> >> 1) Scrap the 256 inode number thing. =A0Instead we'll just put a f=\n" - "lag in the inode\n" - "> >> to say \"Hey, I'm a subvolume\" and then we can do all of the approp=\n" - "riate magic\n" - "> >> that way. =A0This unfortunately will be an incompatible format cha=\n" - "nge, but the\n" - "> >> sooner we get this adressed the easier it will be in the long run.=\n" - " =A0Obviously\n" - "> >> when I say format change I mean via the incompat bits we have, so =\n" - "old fs's won't\n" + "> >> 1) Scrap the 256 inode number thing. \302\240Instead we'll just put a flag in the inode\n" + "> >> to say \"Hey, I'm a subvolume\" and then we can do all of the appropriate magic\n" + "> >> that way. \302\240This unfortunately will be an incompatible format change, but the\n" + "> >> sooner we get this adressed the easier it will be in the long run. \302\240Obviously\n" + "> >> when I say format change I mean via the incompat bits we have, so old fs's won't\n" "> >> be broken and such.\n" "> >>\n" - "> >> 2) Do something like NFS's referral mounts when we cd into a subvo=\n" - "lume. =A0Now we\n" - "> >> just do dentry trickery, but that doesn't make the boundary betwee=\n" - "n subvolumes\n" - "> >> clear, so it will confuse people (and samba) when they walk into a=\n" - " subvolume and\n" - "> >> all of a sudden the inode numbers are the same as in the directory=\n" - " behind them.\n" - "> >> With doing the referral mount thing, each subvolume appears to be =\n" - "its own mount\n" + "> >> 2) Do something like NFS's referral mounts when we cd into a subvolume. \302\240Now we\n" + "> >> just do dentry trickery, but that doesn't make the boundary between subvolumes\n" + "> >> clear, so it will confuse people (and samba) when they walk into a subvolume and\n" + "> >> all of a sudden the inode numbers are the same as in the directory behind them.\n" + "> >> With doing the referral mount thing, each subvolume appears to be its own mount\n" "> >> and that way things like NFS and samba will work properly.\n" "> >>\n" - "> >> I feel like I'm forgetting something here, hopefully somebody will=\n" - " point it out.\n" + "> >> I feel like I'm forgetting something here, hopefully somebody will point it out.\n" "> >>\n" - "> >> =3D=3D=3D Conclusion =3D=3D=3D\n" + "> >> === Conclusion ===\n" "> >>\n" - "> >> There are definitely some wonky things with subvolumes, but I don'=\n" - "t think they\n" - "> >> are things that cannot be fixed now. =A0Some of these changes will=\n" - " require\n" - "> >> incompat format changes, but it's either we fix it now, or later o=\n" - "n down the\n" - "> >> road when BTRFS starts getting used in production really find out =\n" - "how many\n" - "> >> things our current scheme breaks and then have to do the changes t=\n" - "hen. =A0Thanks,\n" + "> >> There are definitely some wonky things with subvolumes, but I don't think they\n" + "> >> are things that cannot be fixed now. \302\240Some of these changes will require\n" + "> >> incompat format changes, but it's either we fix it now, or later on down the\n" + "> >> road when BTRFS starts getting used in production really find out how many\n" + "> >> things our current scheme breaks and then have to do the changes then. \302\240Thanks,\n" "> >>\n" "> >\n" - "> > So now that I've actually looked at everything, it looks like the s=\n" - "emantics are\n" + "> > So now that I've actually looked at everything, it looks like the semantics are\n" "> > all right for subvolumes\n" "> >\n" - "> > 1) readdir - we return the root id in d_ino, which is unique across=\n" - " the fs\n" - "> > 2) stat - we return 256 for all subvolumes, because that is their i=\n" - "node number\n" - "> > 3) dev_t - we setup an anon super for all volumes, so they all get =\n" - "their own\n" + "> > 1) readdir - we return the root id in d_ino, which is unique across the fs\n" + "> > 2) stat - we return 256 for all subvolumes, because that is their inode number\n" + "> > 3) dev_t - we setup an anon super for all volumes, so they all get their own\n" "> > dev_t, which is set properly for all of their children, see below\n" "> >\n" "> > [root@test1244 btrfs-test]# stat .\n" - "> > =A0File: `.'\n" - "> > =A0Size: 20 =A0 =A0 =A0 =A0 =A0 =A0 =A0Blocks: 8 =A0 =A0 =A0 =A0 =A0=\n" - "IO Block: 4096 =A0 directory\n" - "> > Device: 15h/21d Inode: 256 =A0 =A0 =A0 =A0 Links: 1\n" - "> > Access: (0555/dr-xr-xr-x) =A0Uid: ( =A0 =A00/ =A0 =A0root) =A0 Gid:=\n" - " ( =A0 =A00/ =A0 =A0root)\n" + "> > \302\240File: `.'\n" + "> > \302\240Size: 20 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240Blocks: 8 \302\240 \302\240 \302\240 \302\240 \302\240IO Block: 4096 \302\240 directory\n" + "> > Device: 15h/21d Inode: 256 \302\240 \302\240 \302\240 \302\240 Links: 1\n" + "> > Access: (0555/dr-xr-xr-x) \302\240Uid: ( \302\240 \302\2400/ \302\240 \302\240root) \302\240 Gid: ( \302\240 \302\2400/ \302\240 \302\240root)\n" "> > Access: 2010-12-03 15:35:41.931679393 -0500\n" "> > Modify: 2010-12-03 15:35:20.405679493 -0500\n" "> > Change: 2010-12-03 15:35:20.405679493 -0500\n" "> >\n" "> > [root@test1244 btrfs-test]# stat foo\n" - "> > =A0File: `foo'\n" - "> > =A0Size: 12 =A0 =A0 =A0 =A0 =A0 =A0 =A0Blocks: 0 =A0 =A0 =A0 =A0 =A0=\n" - "IO Block: 4096 =A0 directory\n" - "> > Device: 19h/25d Inode: 256 =A0 =A0 =A0 =A0 Links: 1\n" - "> > Access: (0700/drwx------) =A0Uid: ( =A0 =A00/ =A0 =A0root) =A0 Gid:=\n" - " ( =A0 =A00/ =A0 =A0root)\n" + "> > \302\240File: `foo'\n" + "> > \302\240Size: 12 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240Blocks: 0 \302\240 \302\240 \302\240 \302\240 \302\240IO Block: 4096 \302\240 directory\n" + "> > Device: 19h/25d Inode: 256 \302\240 \302\240 \302\240 \302\240 Links: 1\n" + "> > Access: (0700/drwx------) \302\240Uid: ( \302\240 \302\2400/ \302\240 \302\240root) \302\240 Gid: ( \302\240 \302\2400/ \302\240 \302\240root)\n" "> > Access: 2010-12-03 15:35:17.501679393 -0500\n" "> > Modify: 2010-12-03 15:35:59.150680051 -0500\n" "> > Change: 2010-12-03 15:35:59.150680051 -0500\n" "> >\n" "> > [root@test1244 btrfs-test]# stat foo/foobar\n" - "> > =A0File: `foo/foobar'\n" - "> > =A0Size: 0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Blocks: 0 =A0 =A0 =A0 =A0 =A0=\n" - "IO Block: 4096 =A0 regular empty file\n" - "> > Device: 19h/25d Inode: 257 =A0 =A0 =A0 =A0 Links: 1\n" - "> > Access: (0644/-rw-r--r--) =A0Uid: ( =A0 =A00/ =A0 =A0root) =A0 Gid:=\n" - " ( =A0 =A00/ =A0 =A0root)\n" + "> > \302\240File: `foo/foobar'\n" + "> > \302\240Size: 0 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 Blocks: 0 \302\240 \302\240 \302\240 \302\240 \302\240IO Block: 4096 \302\240 regular empty file\n" + "> > Device: 19h/25d Inode: 257 \302\240 \302\240 \302\240 \302\240 Links: 1\n" + "> > Access: (0644/-rw-r--r--) \302\240Uid: ( \302\240 \302\2400/ \302\240 \302\240root) \302\240 Gid: ( \302\240 \302\2400/ \302\240 \302\240root)\n" "> > Access: 2010-12-03 15:35:59.150680051 -0500\n" "> > Modify: 2010-12-03 15:35:59.150680051 -0500\n" "> > Change: 2010-12-03 15:35:59.150680051 -0500\n" "> >\n" - "> > So as far as the user is concerned, everything should come out righ=\n" - "t. =A0Obviously\n" - "> > we had to do the NFS trickery still because as far as VFS is concer=\n" - "ned the\n" - "> > subvolumes are all on the same mount. =A0So the question is this (a=\n" - "nd really this\n" - "> > is directed at Christoph and Bruce and anybody else who may care), =\n" - "is this good\n" - "> > enough, or do we want to have a seperate vfsmount for each subvolum=\n" - "e? =A0Thanks,\n" + "> > So as far as the user is concerned, everything should come out right. \302\240Obviously\n" + "> > we had to do the NFS trickery still because as far as VFS is concerned the\n" + "> > subvolumes are all on the same mount. \302\240So the question is this (and really this\n" + "> > is directed at Christoph and Bruce and anybody else who may care), is this good\n" + "> > enough, or do we want to have a seperate vfsmount for each subvolume? \302\240Thanks,\n" "> >\n" - ">=20\n" + "> \n" "> What are the drawbacks of having a vfsmount for each subvolume?\n" - ">=20\n" - "> Why (besides having to code it up) are you trying to avoid doing it t=\n" - "hat way?\n" + "> \n" + "> Why (besides having to code it up) are you trying to avoid doing it that way?\n" "\n" "It's the having to code it up that way thing, I'm nothing if not lazy.\n" "\n" "Josef\n" "--\n" - "To unsubscribe from this list: send the line \"unsubscribe linux-btrfs\" =\n" - "in\n" + "To unsubscribe from this list: send the line \"unsubscribe linux-btrfs\" in\n" "the body of a message to majordomo@vger.kernel.org\n" More majordomo info at http://vger.kernel.org/majordomo-info.html -ea339a9cbbe52241effd6eec370bce2baf3d367cccb9187df2c944dda53058be +ed8fd3e02a440cdd5f49be55c18a9326823925bc519f05ed564fb20ce73e996b
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.