Currently the resize command is under filesystem, and takes a path to the mounted filesystem. This seems wrong to me. Shouldn''t it be under device, and take a path to a device to resize? Otherwise, how can a resize operation when you have multiple devices make any sense? -- 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
Hallo, Phillip, Du meintest am 30.11.11:> Currently the resize command is under filesystem, and takes a path to > the mounted filesystem. This seems wrong to me. Shouldn''t it be > under device, and take a path to a device to resize?No - it''s a filesystem operation. p.e. You start with a system of 2 disks. They get filled nearly simultaneously. Then you add a 3rd disk (which is empty at that time). Now it''s a good idea to run "balance" for equalizing the filling. Viele Gruesse! Helmut -- 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
On 30 Nov 2011 19:59:00 +0100 "Helmut Hullen" <Hullen@t-online.de> wrote:> > Currently the resize command is under filesystem, and takes a path to > > the mounted filesystem. This seems wrong to me. Shouldn''t it be > > under device, and take a path to a device to resize? > > No - it''s a filesystem operation.Are you sure about that?> > p.e. > You start with a system of 2 disks. They get filled nearly > simultaneously. > Then you add a 3rd disk (which is empty at that time). Now it''s a good > idea to run "balance" for equalizing the filling.What if I need to replace an individual device with a smaller or a larger one? -- With respect, Roman ~~~~~~~~~~~~~~~~~~~~~~~~~~~ "Stallman had a printer, with code he could not see. So he began to tinker, and set the software free."
On Thursday, 01 December, 2011 01:15:47 you wrote:> On 30 Nov 2011 19:59:00 +0100 > > "Helmut Hullen" <Hullen@t-online.de> wrote: > > > Currently the resize command is under filesystem, and takes a path > > > to > > > the mounted filesystem. This seems wrong to me. Shouldn''t it be > > > under device, and take a path to a device to resize? > > > > No - it''s a filesystem operation. > > Are you sure about that?I confirm that. In fact "btrfs filesystem resize" doesn''t change the device(s). It only expands or shrinks the filesystem. Of course if you want to expand the filesystem, you have to expand the underling device *before*. Otherwise if you want to shrink the filesystem, you have to not shrink the device before shrinking the filesystem.> > > p.e. > > You start with a system of 2 disks. They get filled nearly > > simultaneously. > > Then you add a 3rd disk (which is empty at that time). Now it''s a good > > idea to run "balance" for equalizing the filling. > > What if I need to replace an individual device with a smaller or a larger > one?This is a more simpler case As general rule: # btrfs device add <new device> <btrfs root> # btrfs device delete <old device> <btrfs root> May be that the device removing is blocked in some RAID setup. -- gpg key@ keyserver.linux.it: Goffredo Baroncelli (ghigo) <kreijack@inwind.it> Key fingerprint = 4769 7E51 5293 D36C 814E C054 BF04 F161 3DC5 0512 -- 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
Hallo, Roman, Du meintest am 01.12.11:> What if I need to replace an individual device with a smaller or a > larger one?1) add the new device 2) balance (may be it''s not necessary) 3) run "remove" for the "individual" device 4) remove it 5) balance Viele Gruesse! Helmut -- 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
On 30 Nov 2011 20:43:00 +0100 "Helmut Hullen" <Hullen@t-online.de> wrote:> Hallo, Roman, > > Du meintest am 01.12.11: > > > What if I need to replace an individual device with a smaller or a > > larger one? > > 1) add the new device > 2) balance (may be it''s not necessary) > 3) run "remove" for the "individual" device > 4) remove it > 5) balanceOkay, adding a new device wasn''t the best example to explain my point. What I meant is resizing a BTRFS partition, enlarging it or shrinking it as needed, while still on the same device. Of course in the enlarge scenario the partition(or the LV) is resized upwards first, and then the filesystem, and on shrinking it''s vice versa. Suppose I used half of a 1000GB disk for BTRFS (a 500GB partition), and the second half for something else. Now I want to remove this other partition, and make BTRFS occupy the whole disk. Resizing in both ''directions'' seems to work very well on single-device BTRFS filesystems, and also it''s very useful that BTRFS is almost the only modern FS (besides ext4) that can be shrinked. But with multi-device filesystems, don''t you agree it''s non-obvious how (or is not even possible) to resize the areas that BTRFS occupies on individual devices? -- With respect, Roman ~~~~~~~~~~~~~~~~~~~~~~~~~~~ "Stallman had a printer, with code he could not see. So he began to tinker, and set the software free."
On Thursday, 01 December, 2011 02:07:30 you wrote: [...]> Resizing in both ''directions'' seems to work very well on single-device BTRFS > filesystems, and also it''s very useful that BTRFS is almost the only modern > FS (besides ext4) that can be shrinked. But with multi-device filesystems, > don''t you agree it''s non-obvious how (or is not even possible) to resize > the areas that BTRFS occupies on individual devices?I agree that it is not so an obviously syntax, however it is definitely possible to shrink/grow a single disk in a multi disk scenario. The full syntax is the following ([1]) ----------- filesystem resize [<devid>:][+/-]<size>[gkm]|max <path> Resize a filesystem identified by <path>. The <size> parameter specifies the new size of the filesystem. If the prefix + or - is present the size is increased or decreased by the quantity <size>. If no units are specified, the unit of the <size> parameter defaults to bytes. Optionally, the size parameter may be suffixed by one of the following the units designators: ''K'', ''M'', or ''G'', kilobytes, megabytes, or gigabytes, respectively. If ''max'' is passed, the filesystem will occupy all available space on the volume(s). The resize command does not manipulate the size of underlying partition. If you wish to enlarge/reduce a filesystem, you must make sure you can expand the partition before enlarging the filesystem and shrink the partition after reducing the size of the filesystem. <devid> is the id of the device which was grow or shrink, as show by the command btrfs filesystem show. If nothing is passed, the device devid=1 is used. ---------------------- IIRC I sent in the past a patch which added these further info in the man page, but I think that this patch was lost... I have to resubmit another time BR G.Baroncelli [1] http://btrfs.ipv5.de/index.php?title=Btrfs(command) -- gpg key@ keyserver.linux.it: Goffredo Baroncelli (ghigo) <kreijack@inwind.it> Key fingerprint = 4769 7E51 5293 D36C 814E C054 BF04 F161 3DC5 0512 -- 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
Hallo, Roman, Du meintest am 01.12.11:> Okay, adding a new device wasn''t the best example to explain my > point.> What I meant is resizing a BTRFS partition, enlarging it or shrinking > it as needed, while still on the same device.That''s no good example, too. btrfs allows to bundle several disks. Your example is a very special case. Viele Gruesse! Helmut -- 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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 11/30/2011 01:59 PM, Helmut Hullen wrote:> Hallo, Phillip, > > Du meintest am 30.11.11: > >> Currently the resize command is under filesystem, and takes a path to >> the mounted filesystem. This seems wrong to me. Shouldn''t it be >> under device, and take a path to a device to resize? > > No - it''s a filesystem operation.No, it isn''t. You can see the function that implements the resize in the code operates on a specific disk, and the ioctl does take as an argument which disk you are trying to resize. Logically you are adjusting the space that is available on a particular device, which only indirectly affects the filesystem. In other words, the only reason that the size of the filesystem changes is because you have changed the size of a device. In fact, internally device removal is implemented by first resizing the device to 0. It appears that the utility just passes devid=1 to the kernel when you don''t specify it. It should take a dev node as an argument and translate it to the devid for you.> p.e. > You start with a system of 2 disks. They get filled nearly > simultaneously. > Then you add a 3rd disk (which is empty at that time). Now it''s a good > idea to run "balance" for equalizing the filling.balance != resize -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk7Ww+gACgkQJ4UciIs+XuJjlwCgr2u3zvuhYWC0vv9ObdhBS41Z M3MAn09xhEopzuIJdN4QP+8bQvYzhvo1 =Qck2 -----END PGP SIGNATURE----- -- 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
Hallo, Phillip, Du meintest am 30.11.11:>> You start with a system of 2 disks. They get filled nearly >> simultaneously. >> Then you add a 3rd disk (which is empty at that time). Now it''s a >> good idea to run "balance" for equalizing the filling.> balance != resizeI know. p.e. Start with 1 disk with 2 GB and 1 disk with 4 GByte Fill it with 2 Gbyte data, each disk gets 1 GByte. Add a disk with 10 GByte, run "balance": each disk gets about 700 MByte. That has nothing to do with "resize". Viele Gruesse! Helmut -- 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
On 12/1/2011 1:46 AM, Helmut Hullen wrote:>> balance != resize > > I know. > > p.e. > Start with 1 disk with 2 GB and 1 disk with 4 GByte > Fill it with 2 Gbyte data, each disk gets 1 GByte. > > Add a disk with 10 GByte, run "balance": each disk gets about 700 MByte. > > That has nothing to do with "resize".Right, so why are you talking about balance when this thread is about resize? -- 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
Hallo, Phillip, Du meintest am 01.12.11:>>> balance != resize[...]>> That has nothing to do with "resize".> Right, so why are you talking about balance when this thread is about > resize?Ooops - sorry! Viele Gruesse! Helmut -- 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