Re: allocating disk space
On Fri 11 Jan 2019 at 02:12:19 (-0500), Felix Miata wrote: > David Wright composed on 2019-01-09 14:26 (UTC-0600): > > > On Fri 04 Jan 2019 at 19:36:42 (-0500), Felix Miata wrote: > > >> Yes, when filling the disk at the outset. With the escalation of disk > >> sizes over the years, it's > >> become more common not to allocate 100% at the outset. In non-ancient > >> memory I only ever fully > >> allocated with my own disks at the outset with data disks, until small > >> SDDs became cheap. > > > I don't understand the reasoning. > > A Murphy corollary: Junk accumulates according to the amount of space > available for it to fill. > Make the space available when you really need it, and it won't be preoccupied > with junk. Fine, if it helps you. I was unaware that anyone did this for that reason. I know there are more technical difficulties with shrinking partitions than with expanding them, and thought it might be to do with that. > >> Note the relative vastness of unused space. > > > You're not the guy who boots >>100 systems off one disk, are you? > > The one I remember was long ago, not 100 I think, but more than 50, likely > before libata > introduction's 15 partition limit. I recently looked for his page but failed > to find. 100 was superceded long ago; it was 145 by August 2016 when I last looked. http://forums.justlinux.com/showthread.php?147959-How-to-install-and-boot-145-operating-systems-in-a-PC > >> BTW, 36 is near an average count here. I have one with 57, more than one > >> with >40, and > >> probably 8 with >30. My newest PC has 50, though spread across 3 disks, > >> with 20 > >> comprising 10 RAID1 devices, and zero freespace remaining for partition > >> creation. > > > Oh, perhaps you're a rival. :) I assume you foresee adding a lot more > > versions of linux; only three Debian so far? And I would miss a real > > DOS like the old favourite 6.22. > > Except for Etch, I was only using Kubuntu's miscreant Debians until Jessie. > All my 6.22s got > replaced with PC DOS 2000 as soon as impending Y2K caused its availability. > DOS 5 remains available > under cover of OS/2's eComStation progeny (which here runs 24/7). > > > ... if I get my hands on an old newer machine (or is that new older?). > > I get those more often than new-in-original-box, more often broken, which I > am often able to > resurrect. Maybe call them nacqres, for newly acquired > resurrection/recycle/refurb. :-) In the past, the (desktop) systems I acquired were mainly deficient in diskspace. Fortunately I managed to tap the source of 1GB disks that were being used to make it possible to upgrade the secretaries' windows systems (whose older PCs I was acquiring). Occasionally I added memory (or "stole" it from other machines). Since I retired, I've only bought disks. I've never had a new PC. The three desktops I run date from 2000 and 2006 (2). Cheers, David.
Re: allocating disk space
David Wright composed on 2019-01-09 14:26 (UTC-0600): > On Fri 04 Jan 2019 at 19:36:42 (-0500), Felix Miata wrote: >> Yes, when filling the disk at the outset. With the escalation of disk sizes >> over the years, it's >> become more common not to allocate 100% at the outset. In non-ancient memory >> I only ever fully >> allocated with my own disks at the outset with data disks, until small SDDs >> became cheap. > I don't understand the reasoning. A Murphy corollary: Junk accumulates according to the amount of space available for it to fill. Make the space available when you really need it, and it won't be preoccupied with junk. >> Note the relative vastness of unused space. > You're not the guy who boots >>100 systems off one disk, are you? The one I remember was long ago, not 100 I think, but more than 50, likely before libata introduction's 15 partition limit. I recently looked for his page but failed to find. >> BTW, 36 is near an average count here. I have one with 57, more than one >> with >40, and >> probably 8 with >30. My newest PC has 50, though spread across 3 disks, with >> 20 >> comprising 10 RAID1 devices, and zero freespace remaining for partition >> creation. > Oh, perhaps you're a rival. :) I assume you foresee adding a lot more > versions of linux; only three Debian so far? And I would miss a real > DOS like the old favourite 6.22. Except for Etch, I was only using Kubuntu's miscreant Debians until Jessie. All my 6.22s got replaced with PC DOS 2000 as soon as impending Y2K caused its availability. DOS 5 remains available under cover of OS/2's eComStation progeny (which here runs 24/7). > ... if I get my hands on an old newer machine (or is that new older?). I get those more often than new-in-original-box, more often broken, which I am often able to resurrect. Maybe call them nacqres, for newly acquired resurrection/recycle/refurb. :-) -- Evolution as taught in public schools is religion, not science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/
Re: allocating disk space (was: Upgrade Problem)
On Fri 04 Jan 2019 at 19:36:42 (-0500), Felix Miata wrote: > David Wright composed on 2019-01-04 14:27 (UTC-0600): > > On Fri 04 Jan 2019 at 13:41:33 (-0500), Felix Miata wrote: > >> David Wright composed on 2019-01-04 10:19 (UTC-0600): > >> > On Fri 04 Jan 2019 at 04:30:00 (-0500), Felix Miata wrote: > > >> >>> This partitioning scheme seems really odd and unwieldy. > > >> >> Indeed. Considering the absence of a sysadmin, > > >> > What's so unusual about that? > > >> Standing alone, absolutely nothing, but it wasn't standing alone > > > (The OP is standing alone, leaving us aside.) > > > By snipping the rhetorical question that introduces my paragraph, it > > now appears that "unusual" refers to the partitioning scheme. It > > doesn't. > > It wasn't intended to. > > > It refers to the absence of a sysadmin. > > Intended. > > >> >> absence of 2 possible primary partitions on sda, > >> > >> > If the OP partitioned an MBR disk intending to subdivide the > >> > filesystem, then it might be expected that they create an extended > >> > partition. Why bother with holding off until you've got two > >> > primary partitions set up first? > > >> Off the top of my head: > > >> 1-trivial I know, but avoiding seeing fdisk report "Partition table > >> entries are not in disk order" > > >> 2-less trivial: partitions not being in disk order > > > I don't understand. The time sequence would be > > > sda1=primary [ free > > ] > > > sda1=primary [ "sda2"=extended > > ] > > > sda1=primary [ sda5=logicalfree > > ] > > > sda1=primary [ sda5=logical sda6=logical free > > ] > > > sda1=primary [ sda5=logical sda6=logical sda7=logical free > > ] > > > sda1=primary [ sda5=logical sda6=logical sda7=logical sda8=logical > > possibly-free ] > > > What's out of order? > > This looks like it's assuming reference to the OP's disk state, which is not > what I was writing > about. AFAIK, when entries /are/ out of order, far more steps had to have > been involved than those > you listed. > > >> 3-potential to have a primary partition added following a logical, thereby > >> making following > >> freespace unavailable for one or more added logicals (disappearing > >> freespace). > > > With the scenario above, it would be usual to fill the disk with the > > extended partition, so there's no possibility of adding another primary. > > Yes, when filling the disk at the outset. With the escalation of disk sizes > over the years, it's > become more common not to allocate 100% at the outset. In non-ancient memory > I only ever fully > allocated with my own disks at the outset with data disks, until small SDDs > became cheap. I don't understand the reasoning. > Some partitioning tools are better than others at allowing oneself to shoot > oneself in the foot. > > > Here's the partition table of this laptop. Care to guess it's > > evolution? > > > Number Start (sector)End (sector) Size > >12048 2050047 1000.0 MiB > >2 2050048 2582527 260.0 MiB > >3 2582528 4630527 1000.0 MiB > >4 4630528 4892671 128.0 MiB > >5 4892672 347348991 163.3 GiB > >6 347348992 429268991 39.1 GiB / > >7 429268992 511188991 39.1 GiB > >8 511188992 883275775 177.4 GiB/home > >9 883275776 883292159 8.0 MiB > > 10 883292160 892084223 4.2 GiB swap > > 11 892086272 892803071 350.0 MiB > > 12 892803072 894900223 1024.0 MiB > > 13 894900224 947329023 25.0 GiB > > 14 947329024 976773119 14.0 GiB > > > Constrained by an inability to repartition the disk, how would > > you distribute a Debian system across it while wasting the > > least space? > > That's a bit sketchy. Worse then that: I don't have a clue what most of the original partitions were for, and still don't. I just don't touch them. Here's what I inherited: /dev/sda1 2048 2050047 2048000 1000M Windows recovery environment /dev/sda22050048 2582527532480 260M EFI System /dev/sda32582528 4630527 2048000 1000M Lenovo boot partition /dev/sda44630528 4892671262144 128M Microsoft reserved /dev/sda54892672 892086271 887193600 423G Microsoft basic data /dev/sda6 892086272 892803071716800 350M Windows recovery environment /dev/sda7 892803072 894900223 20971521G Microsoft basic data /dev/sda8 894900224 947329023 52428800 25G Microsoft basic data /dev/sda9 947329024 976773119 29444096 14G Windows recovery environment I have no idea why there are three recovery partitions of vastly differing sizes, a manufacturer's boot
Re: allocating disk space (was: Upgrade Problem)
David Wright composed on 2019-01-04 14:27 (UTC-0600): > On Fri 04 Jan 2019 at 13:41:33 (-0500), Felix Miata wrote: >> David Wright composed on 2019-01-04 10:19 (UTC-0600): >> > On Fri 04 Jan 2019 at 04:30:00 (-0500), Felix Miata wrote: >> >>> This partitioning scheme seems really odd and unwieldy. >> >> Indeed. Considering the absence of a sysadmin, >> > What's so unusual about that? >> Standing alone, absolutely nothing, but it wasn't standing alone > (The OP is standing alone, leaving us aside.) > By snipping the rhetorical question that introduces my paragraph, it > now appears that "unusual" refers to the partitioning scheme. It > doesn't. It wasn't intended to. > It refers to the absence of a sysadmin. Intended. >> >> absence of 2 possible primary partitions on sda, >> >> > If the OP partitioned an MBR disk intending to subdivide the >> > filesystem, then it might be expected that they create an extended >> > partition. Why bother with holding off until you've got two >> > primary partitions set up first? >> Off the top of my head: >> 1-trivial I know, but avoiding seeing fdisk report "Partition table entries >> are not in disk order" >> 2-less trivial: partitions not being in disk order > I don't understand. The time sequence would be > sda1=primary [ free >] > sda1=primary [ "sda2"=extended >] > sda1=primary [ sda5=logicalfree >] > sda1=primary [ sda5=logical sda6=logical free >] > sda1=primary [ sda5=logical sda6=logical sda7=logical free >] > sda1=primary [ sda5=logical sda6=logical sda7=logical sda8=logical > possibly-free ] > What's out of order? This looks like it's assuming reference to the OP's disk state, which is not what I was writing about. AFAIK, when entries /are/ out of order, far more steps had to have been involved than those you listed. >> 3-potential to have a primary partition added following a logical, thereby >> making following >> freespace unavailable for one or more added logicals (disappearing >> freespace). > With the scenario above, it would be usual to fill the disk with the > extended partition, so there's no possibility of adding another primary. Yes, when filling the disk at the outset. With the escalation of disk sizes over the years, it's become more common not to allocate 100% at the outset. In non-ancient memory I only ever fully allocated with my own disks at the outset with data disks, until small SDDs became cheap. Some partitioning tools are better than others at allowing oneself to shoot oneself in the foot. > Here's the partition table of this laptop. Care to guess it's > evolution? > Number Start (sector)End (sector) Size >12048 2050047 1000.0 MiB >2 2050048 2582527 260.0 MiB >3 2582528 4630527 1000.0 MiB >4 4630528 4892671 128.0 MiB >5 4892672 347348991 163.3 GiB >6 347348992 429268991 39.1 GiB / >7 429268992 511188991 39.1 GiB >8 511188992 883275775 177.4 GiB/home >9 883275776 883292159 8.0 MiB > 10 883292160 892084223 4.2 GiB swap > 11 892086272 892803071 350.0 MiB > 12 892803072 894900223 1024.0 MiB > 13 894900224 947329023 25.0 GiB > 14 947329024 976773119 14.0 GiB > Constrained by an inability to repartition the disk, how would > you distribute a Debian system across it while wasting the > least space? That's a bit sketchy. How about you do one of mine? Number Start (sector)End (sector) Size 1 63 80324 39.2 MiB 2 80325 578339 243.2 MiB 3 578340 1397654 400.1 MiB 5 1397718 3502169 1.0 GiB swap 6 350223317848214 6.8 GiB WinSYS 71784827830137939 5.9 GiB / 83013800335053829 2.3 GiB /home 93505389344451854 4.5 GiB 104445191846540304 1019.7 MiB /usr/local 114654036858010714 5.5 GiB / 125801077869481124 5.5 GiB / 136948118880951534 5.5 GiB / 148095159892421944 5.5 GiB / 1592422008 103892354 5.5 GiB / 16 103892418 115362764 5.5 GiB / 17 115362828 126833174 5.5 GiB / 18 126833238 138303584 5.5 GiB / 19 138303648 149773994 5.5 GiB / 20 149774058 161244404 5.5 GiB / 21 161244468 172714814 5.5 GiB / 22 172714878 184185224 5.5 GiB / 23
