Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.debian.user > #267515 > unrolled thread
| Started by | Keith Bainbridge <keithrbau@gmail.com> |
|---|---|
| First post | 2024-02-17 03:40 +0100 |
| Last post | 2024-02-19 00:10 +0100 |
| Articles | 7 on this page of 47 — 13 participants |
Back to article view | Back to linux.debian.user
partition reporting full, but not Keith Bainbridge <keithrbau@gmail.com> - 2024-02-17 03:40 +0100
Re: partition reporting full, but not Gremlin <scott-andrews@columbus.rr.com> - 2024-02-17 04:00 +0100
Re: partition reporting full, but not Keith Bainbridge <keithrbau@gmail.com> - 2024-02-17 05:50 +0100
Re: partition reporting full, but not songbird <songbird@anthive.com> - 2024-02-17 13:40 +0100
Re: partition reporting full, but not David Wright <deblis@lionunicorn.co.uk> - 2024-02-17 04:00 +0100
Re: partition reporting full, but not Greg Wooledge <greg@wooledge.org> - 2024-02-17 04:00 +0100
Re: partition reporting full, but not Keith Bainbridge <keithrbau@gmail.com> - 2024-02-17 05:50 +0100
Re: partition reporting full, but not Felix Miata <mrmazda@earthlink.net> - 2024-02-17 07:10 +0100
Re: partition reporting full, but not Keith Bainbridge <keithrbau@gmail.com> - 2024-02-17 10:20 +0100
Re: partition reporting full, but not David Christensen <dpchrist@holgerdanske.com> - 2024-02-18 08:30 +0100
Re: partition reporting full, but not <tomas@tuxteam.de> - 2024-02-17 07:20 +0100
Re: partition reporting full, but not debian-user@howorth.org.uk - 2024-02-17 21:40 +0100
Re: partition reporting full, but not Stefan Monnier <monnier@iro.umontreal.ca> - 2024-02-17 22:10 +0100
Re: partition reporting full, but not Greg Wooledge <greg@wooledge.org> - 2024-02-17 22:10 +0100
Re: partition reporting full, but not Cindy Sue Causey <butterflybytes@gmail.com> - 2024-02-17 23:20 +0100
Re: partition reporting full, but not Keith Bainbridge <keithrbau@gmail.com> - 2024-02-18 05:00 +0100
Re: partition reporting full, but not Keith Bainbridge <keithrbau@gmail.com> - 2024-02-18 05:00 +0100
Re: partition reporting full, but not Keith Bainbridge <keithrbau@gmail.com> - 2024-02-19 00:30 +0100
Re: partition reporting full, but not Max Nikulin <manikulin@gmail.com> - 2024-02-19 03:10 +0100
Re: partition reporting full, but not Keith Bainbridge <keithrbau@gmail.com> - 2024-02-20 07:50 +0100
Re: partition reporting full, but not Felix Miata <mrmazda@earthlink.net> - 2024-02-20 08:50 +0100
Re: partition reporting full, but not <tomas@tuxteam.de> - 2024-02-20 09:40 +0100
Re: partition reporting full, but not Keith Bainbridge <keithrbau@gmail.com> - 2024-02-20 11:30 +0100
Re: partition reporting full, but not <tomas@tuxteam.de> - 2024-02-20 11:40 +0100
Re: partition reporting full, but not Felix Miata <mrmazda@earthlink.net> - 2024-02-20 20:50 +0100
Re: partition reporting full, but not Greg Wooledge <greg@wooledge.org> - 2024-02-20 21:00 +0100
Re: partition reporting full, but not Felix Miata <mrmazda@earthlink.net> - 2024-02-21 00:50 +0100
Re: partition reporting full, but not Keith Bainbridge <keithrbau@gmail.com> - 2024-02-21 02:30 +0100
Re: partition reporting full, but not <tomas@tuxteam.de> - 2024-02-21 06:50 +0100
Re: partition reporting full, but not Felix Miata <mrmazda@earthlink.net> - 2024-02-21 01:40 +0100
Re: partition reporting full, but not Keith Bainbridge <keithrbau@gmail.com> - 2024-02-21 02:00 +0100
Re: partition reporting full, but not Felix Miata <mrmazda@earthlink.net> - 2024-02-21 02:20 +0100
Re: partition reporting full, but not Keith Bainbridge <keithrbau@gmail.com> - 2024-02-20 11:20 +0100
Re: partition reporting full, but not "Thomas Schmitt" <scdbackup@gmx.net> - 2024-02-20 12:40 +0100
Re: partition reporting full, but not debian-user@howorth.org.uk - 2024-02-20 18:20 +0100
Re: partition reporting full, but not Keith Bainbridge <keithrbau@gmail.com> - 2024-02-19 04:30 +0100
Re: partition reporting full, but not <tomas@tuxteam.de> - 2024-02-19 06:50 +0100
Re: partition reporting full, but not David Christensen <dpchrist@holgerdanske.com> - 2024-02-19 08:40 +0100
Re: partition reporting full, but not debian-user@howorth.org.uk - 2024-02-19 12:30 +0100
Re: partition reporting full, but not Keith Bainbridge <keithrbau@gmail.com> - 2024-02-20 08:20 +0100
Re: partition reporting full, but not Keith Bainbridge <keithrbau@gmail.com> - 2024-02-20 09:00 +0100
Re: partition reporting full, but not David Wright <deblis@lionunicorn.co.uk> - 2024-02-21 19:40 +0100
Re: partition reporting full, but not Keith Bainbridge <keithrbau@gmail.com> - 2024-02-19 03:50 +0100
Re: partition reporting full, but not Felix Miata <mrmazda@earthlink.net> - 2024-02-19 03:50 +0100
Re: partition reporting full, but not <tomas@tuxteam.de> - 2024-02-17 07:10 +0100
Re: partition reporting full, but not Max Nikulin <manikulin@gmail.com> - 2024-02-18 04:10 +0100
Re: partition reporting full, but not Keith Bainbridge <keithrbau@gmail.com> - 2024-02-19 00:10 +0100
Page 3 of 3 — ← Prev page 1 2 [3]
| From | Keith Bainbridge <keithrbau@gmail.com> |
|---|---|
| Date | 2024-02-20 09:00 +0100 |
| Message-ID | <I9tcJ-bnbx-3@gated-at.bofh.it> |
| In reply to | #267615 |
On 20/2/24 18:11, Keith Bainbridge wrote: > > On 19/2/24 14:20, Keith Bainbridge wrote: >> >> On 19/2/24 10:26, Keith Bainbridge wrote: >>> >>> On 18/2/24 14:49, Keith Bainbridge wrote: >>>> >>>> On 18/2/24 07:34, debian-user@howorth.org.uk wrote: >>>>> Keith Bainbridge <keithrbau@gmail.com> wrote: >>>>>> Yes the / partitions are btrfs >>>>> >>>>> So the apparently missing space is perhaps taken up by btrfs >>>>> snapshots. >>>>> >>>> >>>> Seems to be the prime suspect. If that's the case, btrfs is NOT >>>> hard- linking the snapshots as timeshift claims it does. The only >>>> way to check is install on ext4 and compare. I have saves enough >>>> free space to do this. >>>> >>>> My effort to date is to move my home to /mnt/data and sim-link it >>>> into / home. df is now showing 2.3GB free on /. df showed /home as >>>> 2.2GB yesterday. At least there is a little space to play with; and >>>> give me time to consider. A fresh install may be worth checking in >>>> snapshots are as big as this all makes them look. >>>> >>>> a few brief answer to other comments will follow >>> >>> >>> So later yesterday afternoon I created a new snapshot with no obvious >>> change is free space. >>> >>> I then update/upgrade. The initial attempt told me >>> 63 upgraded, 3 newly installed, 0 to remove and 0 not upgraded. >>> Need to get 337 MB of archives. >>> After this operation, 473 MB of additional disk space will be used. >>> Do you want to continue? [Y/n] >>> >>> But the 3 kernel related packages failed to install a couple of >>> times. When I finally figured I should check space, there was none. >>> I rolled back to prior to the upgrade, but still no free space. >>> >>> I said sometime in this thread that timeshift (and BiT) use hard >>> links to create progressive copies of the system. The more I think >>> about how hard links reportedly work, I reckon it can't be simply >>> hard links. >>> >>> So I'm starting a new thread on that topic. >>> >>> >> >> So I'm back to see some more helpful hints. Thanks folk >> >> I am convinced that the missing space is used by btrfs snapshot >> process. But WHY is the used space reporting on my daily driver LESS >> than that on the spare machine 29G vs 35G? The original install was >> the same .iso Ah well >> >> I could add some of the spare space the the / partition, but how much? >> Play safe and use the lot, making it 60G compared to 63G on my daily >> driver. (And create some free space off the data partition before it's >> too late.) >> >> Just as well I have time on my hands >> >> Again, thanks to all for your suggestions >> > > I am sure I saw a response to comment of mine, where I was misunderstood > in the numbers I quoted for used space on my daily driver - 29G; and the > space used by the problem machine - 35G. There was a suggestion that I > had not updated it as often as daily driver. I had kept problem box > as up to date as daily until a few days ago when it refused to update > due to lack of space. This is when I discovered I had a problem. It is > switched off at present, pending my deciding whether to expand / > partition or re-install on the free space on ext4. I will delete a few > snapshots before I proceed, just to see what happens - I'll do that > shortly, in fact, now I can see that it may have a bigger affect than I > figured. > > Now a minor amendment to my last note, where deleting snapshots has haad > no bearing on used space. Before I started, df reported 28G used, > compared to 29G used yesterday. Remember my home is sym-linked from > another partition. du is reporting /home is 3M which is the original / > home/keith and re-named to keep it handy IN CASE I need it some day - > like when I did some major surgery on that data partition the other > week. I'm trying to say that nothing I've done overnight has changed > used space. There were no packages to upgrade today. > > df is now reporting 27G used on / confirming btrfs seems to take time > to reflect changes in snapshots. > > Back later. > Back. On booting up problem machine I was greeted with warnings in disk space low on /. I generally don't log into desktop on this machine. Deleted 4 snapshots. df immediately reported used space 33G (down from 35G) and free space 2.9G, up from ~200M at login. I don't think I've EVER seen used space and free space equal size before. I rebooted just to see if anything changed. 10 mins later df is still reporting Size Used Avail Use% Mounted on 36G 33G 2.9G 92% / apt update/upgrade gave me 63 upgraded, 3 newly installed, 0 to remove and 0 not upgraded. Need to get 337 MB of archives. which I reckon is what I got yesterday after I moved my home to my data partition and Quoted from 19Feb at 10:26 (UTC 18Feb at 23:26): I then update/upgrade. The initial attempt told me 63 upgraded, 3 newly installed, 0 to remove and 0 not upgraded. Need to get 337 MB of archives. After this operation, 473 MB of additional disk space will be used. Do you want to continue? [Y/n] But the 3 kernel related packages failed to install a couple of times. When I finally figured I should check space, there was none. I rolled back to prior to the upgrade, but still no free space. And earlier:My effort to date is to move my home to /mnt/data and sym-link it into /home. df is now showing 2.3GB free on /. df showed /home as 2.2GB yesterday. At least there is a little space to play with; and give me time to consider. A fresh install may be worth checking in snapshots are as big as this all makes them look. Back to present, apt is setting up the kernel-image & headers. And completed to upgrade while I typed that last sentence. df is reporting 36G 35G 1004M - still used + free = size Rebooted and df reports 36G 35G 888M 98% / For now, I'll expand / partition and reduce timeshift retention rules When I've completed the reading assignment I have from Sunday, I'll move on. I might start with changing timeshift to use rsync instead of btrfs - just to see how it compares. And put snapshots on another partition. They should really be on a separate drive, but that machine doesn't have a 2nd drive bay that I could see when I swapped the system drive last year when I was given the now 8 year old machine. I'm looking forward to your responses -- All the best Keith Bainbridge keith.bainbridge.3216@gmail.com +61 (0)447 667 468 UTC + 10:00
[toc] | [prev] | [next] | [standalone]
| From | David Wright <deblis@lionunicorn.co.uk> |
|---|---|
| Date | 2024-02-21 19:40 +0100 |
| Message-ID | <I9ZFD-bGNi-7@gated-at.bofh.it> |
| In reply to | #267570 |
On Mon 19 Feb 2024 at 10:26:05 (+1100), Keith Bainbridge wrote: > On 18/2/24 14:49, Keith Bainbridge wrote: > > On 18/2/24 07:34, debian-user@howorth.org.uk wrote: > > > Keith Bainbridge wrote: > > > > Yes the / partitions are btrfs > > > > > > So the apparently missing space is perhaps taken up by btrfs snapshots. > > > > > > > Seems to be the prime suspect. If that's the case, btrfs is NOT > > hard- linking the snapshots as timeshift claims it does. The only > > way to check is install on ext4 and compare. I have saves enough > > free space to do this. > > > > My effort to date is to move my home to /mnt/data and sim-link it > > into / home. df is now showing 2.3GB free on /. df showed /home > > as 2.2GB yesterday. At least there is a little space to play > > with; and give me time to consider. A fresh install may be worth > > checking in snapshots are as big as this all makes them look. > > > > a few brief answer to other comments will follow > > > So later yesterday afternoon I created a new snapshot with no obvious > change is free space. That would seem reasonable, as there's not much more to do than note which files the snapshot contains. > I then update/upgrade. The initial attempt told me > 63 upgraded, 3 newly installed, 0 to remove and 0 not upgraded. > Need to get 337 MB of archives. > After this operation, 473 MB of additional disk space will be used. > Do you want to continue? [Y/n] > > But the 3 kernel related packages failed to install a couple of times. > When I finally figured I should check space, there was none. I > rolled back to prior to the upgrade, but still no free space. > > I said sometime in this thread that timeshift (and BiT) use hard links > to create progressive copies of the system. The more I think about how > hard links reportedly work, I reckon it can't be simply hard links. Reading a tiny bit of the BTRFS docs, I would suggest that you're not taking Block Groups into account. If BTRFS allocates data chunks in blocks of 1GB, then it's conceivable that an upgrade involving 473MB of data, plus the consequential increase in the size of the snapshot, could all reside in a very recently created Block Group. Put another way, df would see no change in Used and Available (as no new Block Group allocation), whereas I would expect btrfs filesystem df to report a change here (because it knows what's within its Block Groups): > Data, single: total=32.80GiB, used=31.94GiB > Tue 20Feb2024@20:57:45 Cheers, David.
[toc] | [prev] | [next] | [standalone]
| From | Keith Bainbridge <keithrbau@gmail.com> |
|---|---|
| Date | 2024-02-19 03:50 +0100 |
| Message-ID | <I91Tb-b6zZ-5@gated-at.bofh.it> |
| In reply to | #267558 |
On 19/2/24 13:41, Felix Miata wrote: > would be some places to start. Didn't you do your > https://btrfs.readthedocs.io/en/latest/btrfs-filesystem.html > reading yet? ?_? My eyes have glazed over too often, already. I know I have to get back, but that NEED to do it is making it harder. -- All the best Keith Bainbridge keith.bainbridge.3216@gmail.com +61 (0)447 667 468 UTC + 10:00
[toc] | [prev] | [next] | [standalone]
| From | Felix Miata <mrmazda@earthlink.net> |
|---|---|
| Date | 2024-02-19 03:50 +0100 |
| Message-ID | <I91Tb-b6zZ-7@gated-at.bofh.it> |
| In reply to | #267558 |
Keith Bainbridge composed on 2024-02-18 14:49 (UTC+1100): > debian-user@howorth.org.uk wrote: >> So the apparently missing space is perhaps taken up by btrfs snapshots. > Seems to be the prime suspect. While snapshotting is obviously a consumer, until you use the right tool for the job, you won't know anything meaningful about overall space usage on btrfs. btrfs filesystem df btrfs filesystem du btrfs filesysten show would be some places to start. Didn't you do your https://btrfs.readthedocs.io/en/latest/btrfs-filesystem.html reading yet? ?_? -- Evolution as taught in public schools is, like religion, based on faith, not based on science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata
[toc] | [prev] | [next] | [standalone]
| From | <tomas@tuxteam.de> |
|---|---|
| Date | 2024-02-17 07:10 +0100 |
| Message-ID | <I8m3D-aHiR-1@gated-at.bofh.it> |
| In reply to | #267518 |
[Multipart message — attachments visible in raw view] — view raw
On Fri, Feb 16, 2024 at 09:52:22PM -0500, Greg Wooledge wrote: > On Sat, Feb 17, 2024 at 01:38:56PM +1100, Keith Bainbridge wrote: > > >> sudo df -h / > > Filesystem Size Used Avail Use% Mounted on > > /dev/sda3 36G 35G 100M 100% / > > First off: you don't need sudo for this, ever. > > Second: what kind of file system is this? > > > sudo du -hPx --max-depth=1 / > > 0 /mnt > > 181M /boot > > 15M /etc > > 0 /media > > 236M /opt > > 336K /root > > 0 /srv > > 4.0K /tmp > > 8.1G /usr > > 726M /var > > 9.2G / > > So I guess the question is "Where's the rest of that 35 G used data?" > > Conspicuously missing from this output is /home. Is that a separate > file system? If so, you *could* have data inside the /home directory > of the root file system, which is hidden by the /home file system that's > mounted over it. You'd need to unmount /home to check. It's not a > super probable situation, but it's worth checking. Absolutely. What I miss, too, is lost+found (not every file system has that,i though). > The same applies to any other directory that's got a file system mounted > on it. Yes, looking "under" the mounts is a very good idea. > Or... it could be some bizarre btrfs crap. If this is a btrfs. We're all curious :-) Cheers -- t
[toc] | [prev] | [next] | [standalone]
| From | Max Nikulin <manikulin@gmail.com> |
|---|---|
| Date | 2024-02-18 04:10 +0100 |
| Message-ID | <I8FIZ-aT0b-1@gated-at.bofh.it> |
| In reply to | #267518 |
On 17/02/2024 09:52, Greg Wooledge wrote:
> If so, you *could* have data inside the /home directory
> of the root file system, which is hidden by the /home file system that's
> mounted over it. You'd need to unmount /home to check.
A less intrusive way to inspect shadowed directories is bind mounts.
mkdir /tmp/root
mount --bind / /tmp/root
[toc] | [prev] | [next] | [standalone]
| From | Keith Bainbridge <keithrbau@gmail.com> |
|---|---|
| Date | 2024-02-19 00:10 +0100 |
| Message-ID | <I8Ysh-b4K4-3@gated-at.bofh.it> |
| In reply to | #267556 |
On 18/2/24 14:08, Max Nikulin wrote: > On 17/02/2024 09:52, Greg Wooledge wrote: >> If so, you *could* have data inside the /home directory >> of the root file system, which is hidden by the /home file system that's >> mounted over it. You'd need to unmount /home to check. > > A less intrusive way to inspect shadowed directories is bind mounts. > > mkdir /tmp/root > mount --bind / /tmp/root > Thank you Max This has proved a real boon -- All the best Keith Bainbridge keith.bainbridge.3216@gmail.com +61 (0)447 667 468 UTC + 10:00
[toc] | [prev] | [standalone]
Page 3 of 3 — ← Prev page 1 2 [3]
Back to top | Article view | linux.debian.user
csiph-web