Re: 9.0-RC2 - bsdinstall miscount of remaining diskspace after partition deletion.
On Monday, November 21, 2011 1:05:28 pm Nathan Whitehorn wrote: On 11/21/11 11:52, John Baldwin wrote: On Saturday, November 19, 2011 7:07:58 pm Nathan Whitehorn wrote: On 11/18/11 17:09, nev...@tx.net wrote: If you are performating a manual partion in 9.0-RC2 bsdinstall and you delete any created partition except the most recently created one, the total remaining space will be miscalculated. Reproducable as shown below. Workaround: if you delete a partition that is not the last partition that was created, delete all partitions created after that partition before continuing. Order does not seem to be important. The results are similar with other hard drive sizes, with the i386 or amd64 distributions, and with either 9.0-RC2 or 9.0-RC1 (I did not go back and check install discs prior to RC1) Reproducing the miscount: A 114 GB drive is used for this example: Select Manual Partitioning Perform the first Create on the drive and select GPT Creating the first partition: Add Partition size shows 114GB Change size to 4GB, set mountpoint to / and tab to OK (agree to the boot partition creation) Create a second partition: Add Partition size shows 110GB Adjust size to 10GB, set mountpoint to /usr and tab to OK Create a third partition: Add Partition size shows 100GB Adjust size to 20GB, set mountpoint to /var, and tab to OK Create a 4th partition: size shows 80GB remaining Adjust size to 40GB, set mountpoint to /data, and tab to OK. There is 40 GB remaining on the drive. Now change the size of /var. First, delete the currently configured /var partition. In the Partition Editor, adding up all the lines on the screen shows 54GB (plus a 64K boot) as allocated, so there should now be 60GB remaining. But the deleted /var space has not been added back into the total. Select Create again: Add Partition size shows 40GB Adjust size to 30GB, set mountpoint as /var, tab to OK A subsequent Create will show that 20GB is remaining, rather than the actual remaining 30GB. Selecting any size 20GB or larger for /home will give you a 20GB partition, and then an additional create will show the 10GB. This isn't a bug. The partitions are laid out on disk already, and, because you deleted one in the middle, the largest *contiguous* block of free space is 20GB, which is what is shown and the maximum it is possible to create. That's why you can make one 20 GB partition and one 10 GB partition, but not a single 30 GB one. Except that this is not intuitive. If I'm laying out a disk and haven't committed the changes yet, it should be possible to do things like resize an existing partition, or have the installer realize that if you delete one partition the other partitions that are pending should just move up to maximize free space automatically. I ran into this when first trying the new installer last week where you could not modify a pending partition's size which I found non-intuitive. There doesn't seem to be an easy solution though. Not laying them out on disk is extremely fragile: the installer needs to know tons of tiny details about the partition schemes (alignment constraints, partition numbering/lettering, available space after the header, the list is very long) or it will break. One simple example is that whether a partition is ad0s1 or ad0s3 depends on its order on the disk (or in the partition table anyway). If I have an ad0s2 and s3, and delete the s2, should the new partition be s2 or s4? That depends on a lot of things the installer can't easily know about, and that even if it could, simulating which would be dangerous. I think you would need to not commit to as many details up front and figure out the names and exact sizes when doing the commit if you wanted to support this (i.e. you know the user wants a partition of 4GB, another one of 2GB, and one for rest of disk, and you only bind those to specific names and exact sizes on the final commit). -- John Baldwin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: 9.0-RC2 - bsdinstall miscount of remaining diskspace after partition deletion.
On 11/22/11 07:46, John Baldwin wrote: On Monday, November 21, 2011 1:05:28 pm Nathan Whitehorn wrote: On 11/21/11 11:52, John Baldwin wrote: On Saturday, November 19, 2011 7:07:58 pm Nathan Whitehorn wrote: On 11/18/11 17:09, nev...@tx.net wrote: If you are performating a manual partion in 9.0-RC2 bsdinstall and you delete any created partition except the most recently created one, the total remaining space will be miscalculated. Reproducable as shown below. Workaround: if you delete a partition that is not the last partition that was created, delete all partitions created after that partition before continuing. Order does not seem to be important. The results are similar with other hard drive sizes, with the i386 or amd64 distributions, and with either 9.0-RC2 or 9.0-RC1 (I did not go back and check install discs prior to RC1) Reproducing the miscount: A 114 GB drive is used for this example: Select Manual Partitioning Perform the first Create on the drive and select GPT Creating the first partition: Add Partition size shows 114GB Change size to 4GB, set mountpoint to / and tab to OK (agree to the boot partition creation) Create a second partition: Add Partition size shows 110GB Adjust size to 10GB, set mountpoint to /usr and tab to OK Create a third partition: Add Partition size shows 100GB Adjust size to 20GB, set mountpoint to /var, and tab to OK Create a 4th partition: size shows 80GB remaining Adjust size to 40GB, set mountpoint to /data, and tab to OK. There is 40 GB remaining on the drive. Now change the size of /var. First, delete the currently configured /var partition. In the Partition Editor, adding up all the lines on the screen shows 54GB (plus a 64K boot) as allocated, so there should now be 60GB remaining. But the deleted /var space has not been added back into the total. Select Create again: Add Partition size shows 40GB Adjust size to 30GB, set mountpoint as /var, tab to OK A subsequent Create will show that 20GB is remaining, rather than the actual remaining 30GB. Selecting any size 20GB or larger for /home will give you a 20GB partition, and then an additional create will show the 10GB. This isn't a bug. The partitions are laid out on disk already, and, because you deleted one in the middle, the largest *contiguous* block of free space is 20GB, which is what is shown and the maximum it is possible to create. That's why you can make one 20 GB partition and one 10 GB partition, but not a single 30 GB one. Except that this is not intuitive. If I'm laying out a disk and haven't committed the changes yet, it should be possible to do things like resize an existing partition, or have the installer realize that if you delete one partition the other partitions that are pending should just move up to maximize free space automatically. I ran into this when first trying the new installer last week where you could not modify a pending partition's size which I found non-intuitive. There doesn't seem to be an easy solution though. Not laying them out on disk is extremely fragile: the installer needs to know tons of tiny details about the partition schemes (alignment constraints, partition numbering/lettering, available space after the header, the list is very long) or it will break. One simple example is that whether a partition is ad0s1 or ad0s3 depends on its order on the disk (or in the partition table anyway). If I have an ad0s2 and s3, and delete the s2, should the new partition be s2 or s4? That depends on a lot of things the installer can't easily know about, and that even if it could, simulating which would be dangerous. I think you would need to not commit to as many details up front and figure out the names and exact sizes when doing the commit if you wanted to support this (i.e. you know the user wants a partition of 4GB, another one of 2GB, and one for rest of disk, and you only bind those to specific names and exact sizes on the final commit). Exactly. It requires a fundamental rewrite of the code -- something also fraught with peril because some partition schemes (VTOC8 comes to mind) have ... interesting ... rules that the partitioner would need to know about. -Nathan ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: 9.0-RC2 - bsdinstall miscount of remaining diskspace after partition deletion.
On Saturday, November 19, 2011 7:07:58 pm Nathan Whitehorn wrote: On 11/18/11 17:09, nev...@tx.net wrote: If you are performating a manual partion in 9.0-RC2 bsdinstall and you delete any created partition except the most recently created one, the total remaining space will be miscalculated. Reproducable as shown below. Workaround: if you delete a partition that is not the last partition that was created, delete all partitions created after that partition before continuing. Order does not seem to be important. The results are similar with other hard drive sizes, with the i386 or amd64 distributions, and with either 9.0-RC2 or 9.0-RC1 (I did not go back and check install discs prior to RC1) Reproducing the miscount: A 114 GB drive is used for this example: Select Manual Partitioning Perform the first Create on the drive and select GPT Creating the first partition: Add Partition size shows 114GB Change size to 4GB, set mountpoint to / and tab to OK (agree to the boot partition creation) Create a second partition: Add Partition size shows 110GB Adjust size to 10GB, set mountpoint to /usr and tab to OK Create a third partition: Add Partition size shows 100GB Adjust size to 20GB, set mountpoint to /var, and tab to OK Create a 4th partition: size shows 80GB remaining Adjust size to 40GB, set mountpoint to /data, and tab to OK. There is 40 GB remaining on the drive. Now change the size of /var. First, delete the currently configured /var partition. In the Partition Editor, adding up all the lines on the screen shows 54GB (plus a 64K boot) as allocated, so there should now be 60GB remaining. But the deleted /var space has not been added back into the total. Select Create again: Add Partition size shows 40GB Adjust size to 30GB, set mountpoint as /var, tab to OK A subsequent Create will show that 20GB is remaining, rather than the actual remaining 30GB. Selecting any size 20GB or larger for /home will give you a 20GB partition, and then an additional create will show the 10GB. This isn't a bug. The partitions are laid out on disk already, and, because you deleted one in the middle, the largest *contiguous* block of free space is 20GB, which is what is shown and the maximum it is possible to create. That's why you can make one 20 GB partition and one 10 GB partition, but not a single 30 GB one. Except that this is not intuitive. If I'm laying out a disk and haven't committed the changes yet, it should be possible to do things like resize an existing partition, or have the installer realize that if you delete one partition the other partitions that are pending should just move up to maximize free space automatically. I ran into this when first trying the new installer last week where you could not modify a pending partition's size which I found non-intuitive. -- John Baldwin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: 9.0-RC2 - bsdinstall miscount of remaining diskspace after partition deletion.
On 11/21/11 11:52, John Baldwin wrote: On Saturday, November 19, 2011 7:07:58 pm Nathan Whitehorn wrote: On 11/18/11 17:09, nev...@tx.net wrote: If you are performating a manual partion in 9.0-RC2 bsdinstall and you delete any created partition except the most recently created one, the total remaining space will be miscalculated. Reproducable as shown below. Workaround: if you delete a partition that is not the last partition that was created, delete all partitions created after that partition before continuing. Order does not seem to be important. The results are similar with other hard drive sizes, with the i386 or amd64 distributions, and with either 9.0-RC2 or 9.0-RC1 (I did not go back and check install discs prior to RC1) Reproducing the miscount: A 114 GB drive is used for this example: Select Manual Partitioning Perform the first Create on the drive and select GPT Creating the first partition: Add Partition size shows 114GB Change size to 4GB, set mountpoint to / and tab to OK (agree to the boot partition creation) Create a second partition: Add Partition size shows 110GB Adjust size to 10GB, set mountpoint to /usr and tab to OK Create a third partition: Add Partition size shows 100GB Adjust size to 20GB, set mountpoint to /var, and tab to OK Create a 4th partition: size shows 80GB remaining Adjust size to 40GB, set mountpoint to /data, and tab to OK. There is 40 GB remaining on the drive. Now change the size of /var. First, delete the currently configured /var partition. In the Partition Editor, adding up all the lines on the screen shows 54GB (plus a 64K boot) as allocated, so there should now be 60GB remaining. But the deleted /var space has not been added back into the total. Select Create again: Add Partition size shows 40GB Adjust size to 30GB, set mountpoint as /var, tab to OK A subsequent Create will show that 20GB is remaining, rather than the actual remaining 30GB. Selecting any size 20GB or larger for /home will give you a 20GB partition, and then an additional create will show the 10GB. This isn't a bug. The partitions are laid out on disk already, and, because you deleted one in the middle, the largest *contiguous* block of free space is 20GB, which is what is shown and the maximum it is possible to create. That's why you can make one 20 GB partition and one 10 GB partition, but not a single 30 GB one. Except that this is not intuitive. If I'm laying out a disk and haven't committed the changes yet, it should be possible to do things like resize an existing partition, or have the installer realize that if you delete one partition the other partitions that are pending should just move up to maximize free space automatically. I ran into this when first trying the new installer last week where you could not modify a pending partition's size which I found non-intuitive. There doesn't seem to be an easy solution though. Not laying them out on disk is extremely fragile: the installer needs to know tons of tiny details about the partition schemes (alignment constraints, partition numbering/lettering, available space after the header, the list is very long) or it will break. One simple example is that whether a partition is ad0s1 or ad0s3 depends on its order on the disk (or in the partition table anyway). If I have an ad0s2 and s3, and delete the s2, should the new partition be s2 or s4? That depends on a lot of things the installer can't easily know about, and that even if it could, simulating which would be dangerous. -Nathan ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: 9.0-RC2 - bsdinstall miscount of remaining diskspace after partition deletion.
On Saturday, November 19, 2011 7:07:58 pm Nathan Whitehorn wrote: On 11/18/11 17:09, nev...@tx.net wrote: If you are performating a manual partion in 9.0-RC2 bsdinstall and you delete any created partition except the most recently created one, the total remaining space will be miscalculated. Reproducable as shown below. Workaround: if you delete a partition that is not the last partition that was created, delete all partitions created after that partition before continuing. Order does not seem to be important. The results are similar with other hard drive sizes, with the i386 or amd64 distributions, and with either 9.0-RC2 or 9.0-RC1 (I did not go back and check install discs prior to RC1) Reproducing the miscount: A 114 GB drive is used for this example: Select Manual Partitioning Perform the first Create on the drive and select GPT Creating the first partition: Add Partition size shows 114GB Change size to 4GB, set mountpoint to / and tab to OK (agree to the boot partition creation) Create a second partition: Add Partition size shows 110GB Adjust size to 10GB, set mountpoint to /usr and tab to OK Create a third partition: Add Partition size shows 100GB Adjust size to 20GB, set mountpoint to /var, and tab to OK Create a 4th partition: size shows 80GB remaining Adjust size to 40GB, set mountpoint to /data, and tab to OK. There is 40 GB remaining on the drive. Now change the size of /var. First, delete the currently configured /var partition. In the Partition Editor, adding up all the lines on the screen shows 54GB (plus a 64K boot) as allocated, so there should now be 60GB remaining. But the deleted /var space has not been added back into the total. Select Create again: Add Partition size shows 40GB Adjust size to 30GB, set mountpoint as /var, tab to OK A subsequent Create will show that 20GB is remaining, rather than the actual remaining 30GB. Selecting any size 20GB or larger for /home will give you a 20GB partition, and then an additional create will show the 10GB. This isn't a bug. The partitions are laid out on disk already, and, because you deleted one in the middle, the largest *contiguous* block of free space is 20GB, which is what is shown and the maximum it is possible to create. That's why you can make one 20 GB partition and one 10 GB partition, but not a single 30 GB one. Except that this is not intuitive. If I'm laying out a disk and haven't committed the changes yet, it should be possible to do things like resize an existing partition, or have the installer realize that if you delete one partition the other partitions that are pending should just move up to maximize free space automatically. I ran into this when first trying the new installer last week where you could not modify a pending partition's size which I found non-intuitive. -- John Baldwin ___ Issue is not just because of deleting a partition in the middle, but also because the installer doesn't use up 100% of the remaining disk space... I'm doing an install onto a 232GB drive now. Deleted all partitions, and created the following: ada0p1 64KB freebsd-boot ada0p2 10GB freebsd-ufs / ada0p3 1GB freebsd-swap none When I go to create 'p4' it automatically fills the disk space to 221GB, so now I have: ada0p4 221GB freebsd-ufs /data ..BUT I can still create 'p5' with a size of 907MB! Workaround is to delete 'p4' and hit 'Create' but for size instead of accepting default of '221GB' I input '321GB' [well over the physical disk size] - It creates 'p5' with size 221GB and now when I go to create 'p5' I get the expected 'No free space left on device'. Both times the installer showed 221GB for /data, but one time it still had 907MB left to create a fifth partition - So it rounds down the 221.9GB to 221GB giving a false impression the disk is 100% full. and yes, when I delete 'p2' and my 221GB 'p4', I can create another partition of 221GB [which is now p2] and then create another 10GB partition which becomes p4. The installer should move swap to p2 and allow me to recreate p3 with size of 331GB instead of this result: ada0p1 64kB freebsd-boot ada0p3 1GB freebsd-swap ada0p2 221GB freebsd-ufs /data ada0p4 10GB freebsd-ufs / How did p2 become 221GB when originally it was only 10GB? Seems nothing is written to disk at this point and the installer should have dynamically moved p3 into p2, and allowed to use the remaining continous disk space for p3 of 331GB [after all, it moved 221GB from p4 to p2 without a problem]. ]Peter[ There are more advanced user installer issues which I'm documenting. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to
Re: 9.0-RC2 - bsdinstall miscount of remaining diskspace after partition deletion.
On 11/18/11 17:09, nev...@tx.net wrote: If you are performating a manual partion in 9.0-RC2 bsdinstall and you delete any created partition except the most recently created one, the total remaining space will be miscalculated. Reproducable as shown below. Workaround: if you delete a partition that is not the last partition that was created, delete all partitions created after that partition before continuing. Order does not seem to be important. The results are similar with other hard drive sizes, with the i386 or amd64 distributions, and with either 9.0-RC2 or 9.0-RC1 (I did not go back and check install discs prior to RC1) Reproducing the miscount: A 114 GB drive is used for this example: Select Manual Partitioning Perform the first Create on the drive and select GPT Creating the first partition: Add Partition size shows 114GB Change size to 4GB, set mountpoint to / and tab to OK (agree to the boot partition creation) Create a second partition: Add Partition size shows 110GB Adjust size to 10GB, set mountpoint to /usr and tab to OK Create a third partition: Add Partition size shows 100GB Adjust size to 20GB, set mountpoint to /var, and tab to OK Create a 4th partition: size shows 80GB remaining Adjust size to 40GB, set mountpoint to /data, and tab to OK. There is 40 GB remaining on the drive. Now change the size of /var. First, delete the currently configured /var partition. In the Partition Editor, adding up all the lines on the screen shows 54GB (plus a 64K boot) as allocated, so there should now be 60GB remaining. But the deleted /var space has not been added back into the total. Select Create again: Add Partition size shows 40GB Adjust size to 30GB, set mountpoint as /var, tab to OK A subsequent Create will show that 20GB is remaining, rather than the actual remaining 30GB. Selecting any size 20GB or larger for /home will give you a 20GB partition, and then an additional create will show the 10GB. This isn't a bug. The partitions are laid out on disk already, and, because you deleted one in the middle, the largest *contiguous* block of free space is 20GB, which is what is shown and the maximum it is possible to create. That's why you can make one 20 GB partition and one 10 GB partition, but not a single 30 GB one. -Nathan ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
9.0-RC2 - bsdinstall miscount of remaining diskspace after partition deletion.
If you are performating a manual partion in 9.0-RC2 bsdinstall and you delete any created partition except the most recently created one, the total remaining space will be miscalculated. Reproducable as shown below. Workaround: if you delete a partition that is not the last partition that was created, delete all partitions created after that partition before continuing. Order does not seem to be important. The results are similar with other hard drive sizes, with the i386 or amd64 distributions, and with either 9.0-RC2 or 9.0-RC1 (I did not go back and check install discs prior to RC1) Reproducing the miscount: A 114 GB drive is used for this example: Select Manual Partitioning Perform the first Create on the drive and select GPT Creating the first partition: Add Partition size shows 114GB Change size to 4GB, set mountpoint to / and tab to OK (agree to the boot partition creation) Create a second partition: Add Partition size shows 110GB Adjust size to 10GB, set mountpoint to /usr and tab to OK Create a third partition: Add Partition size shows 100GB Adjust size to 20GB, set mountpoint to /var, and tab to OK Create a 4th partition: size shows 80GB remaining Adjust size to 40GB, set mountpoint to /data, and tab to OK. There is 40 GB remaining on the drive. Now change the size of /var. First, delete the currently configured /var partition. In the Partition Editor, adding up all the lines on the screen shows 54GB (plus a 64K boot) as allocated, so there should now be 60GB remaining. But the deleted /var space has not been added back into the total. Select Create again: Add Partition size shows 40GB Adjust size to 30GB, set mountpoint as /var, tab to OK A subsequent Create will show that 20GB is remaining, rather than the actual remaining 30GB. Selecting any size 20GB or larger for /home will give you a 20GB partition, and then an additional create will show the 10GB. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: 9.0-RC2 - bsdinstall miscount of remaining diskspace after partition deletion.
nev...@tx.net wrote: If you are performating a manual partion in 9.0-RC2 bsdinstall and you delete any created partition except the most recently created one, the total remaining space will be miscalculated. Reproducable as shown below. Workaround: if you delete a partition that is not the last partition that was created, delete all partitions created after that partition before continuing. Order does not seem to be important. The results are similar with other hard drive sizes, with the i386 or amd64 distributions, and with either 9.0-RC2 or 9.0-RC1 (I did not go back and check install discs prior to RC1) Reproducing the miscount: A 114 GB drive is used for this example: Select Manual Partitioning Perform the first Create on the drive and select GPT Creating the first partition: Add Partition size shows 114GB Change size to 4GB, set mountpoint to / and tab to OK (agree to the boot partition creation) Create a second partition: Add Partition size shows 110GB Adjust size to 10GB, set mountpoint to /usr and tab to OK Create a third partition: Add Partition size shows 100GB Adjust size to 20GB, set mountpoint to /var, and tab to OK Create a 4th partition: size shows 80GB remaining Adjust size to 40GB, set mountpoint to /data, and tab to OK. There is 40 GB remaining on the drive. Now change the size of /var. First, delete the currently configured /var partition. In the Partition Editor, adding up all the lines on the screen shows 54GB (plus a 64K boot) as allocated, so there should now be 60GB remaining. But the deleted /var space has not been added back into the total. Select Create again: Add Partition size shows 40GB Adjust size to 30GB, set mountpoint as /var, tab to OK A subsequent Create will show that 20GB is remaining, rather than the actual remaining 30GB. Selecting any size 20GB or larger for /home will give you a 20GB partition, and then an additional create will show the 10GB. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org You should submit this as a pr. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
