(SOLVED) Drive suddenly full

[Mr. Lumbergh]

I started unpacking a zip archive yesterday that contains several images, and after about 10 min the system became very sluggish and I got a warning that the disk was 95% full in the KDE tray. A moment later the same notification icon popped up a warning saying the disk was 100% full, and looking at the destination folder it did look like only about half of the images had been successfully extracted. Worth mentioning, I have this install set up on an LVM.
Obviously this got my attention, and so:

Code: Select all

lumbergh@Initech:~$ df -h
Filesystem                         Size  Used Avail Use% Mounted on
udev                                32G     0   32G   0% /dev
tmpfs                              6.3G  9.8M  6.3G   1% /run
/dev/mapper/HAL9000--Deb--vg-root  853G  845G  6.3G   1% /
tmpfs                               32G  245M   32G   1% /dev/shm
tmpfs                              5.0M  4.0K  5.0M   1% /run/lock
tmpfs                               32G     0   32G   0% /sys/fs/cgroup
/dev/sdc2                          237M  136M   89M  61% /boot
/dev/sdc1                          511M  5.3M  506M   2% /boot/efi
tmpfs                              6.3G   48K  6.3G   1% /run/user/1000

I tried to drill down into what was causing this with

Code: Select all

sudo du -a /home | sort -n -r | head -n 10

but it wouldn't let me dig down into dev/mapper. What I did instead was run an

Code: Select all

rm -r 

on the file the archive created as it unpacked and rebooted. Now,

Code: Select all

lumbergh@Initech:~$ df -h
Filesystem                         Size  Used Avail Use% Mounted on
udev                                32G     0   32G   0% /dev
tmpfs                              6.3G  9.8M  6.3G   1% /run
/dev/mapper/HAL9000--Deb--vg-root  853G  390G  420G  49% /
tmpfs                               32G  245M   32G   1% /dev/shm
tmpfs                              5.0M  4.0K  5.0M   1% /run/lock
tmpfs                               32G     0   32G   0% /sys/fs/cgroup
/dev/sdc2                          237M  136M   89M  61% /boot
/dev/sdc1                          511M  5.3M  506M   2% /boot/efi
tmpfs                              6.3G   48K  6.3G   1% /run/user/1000

The system seems to be behaving now, but I'm worried that a bunch of links were created that the system might still try to write to despite folder being deleted; I've heard about this sort of situation sometimes doing that. So, I have a couple questions:

1. How would I go about checking for and clearing any such links, if that is indeed part of the problem I had earlier?
2. I started GParted as a sanity check and it still shows the partition as 100% full with only 12 MiB unused; am I correct in thinking this is due to the system being on an LVM?
3. Is there anything else you'd recommend I check before calling this good?

Thanks.

[cuckooflew]

y Mr. Lumbergh » 2020-08-26 20:39
I started unpacking a zip archive yesterday that contains several images, and after about 10 min the system became very sluggish and I got a warning that the disk was 95% full in the KDE tray

I don't see what this "zip achirve" is, where it came from, name , etc.... But I would be worried, a lot can be done in 10 minuets, I hope you have a good back up of your system, made before you did this

1. How would I go about checking for and clearing any such links, if that is indeed part of the problem I had earlier?

I don't know, it would help to have the name of the mysterious zip file I think,...
2. I don't use gparted, not much any way...don't trust it.

3. Is there anything else you'd recommend I check before calling this good?

Depends on what the zip file was, I will leave it at that for now.
(Usually zip files are intended for Windows, but sometimes they are available for Linux , with claims that it can be used on a linux system) 10 minuets was enough time to extract a lot of data and upload it, or like you said, it could have established links, and be uploading your data some where right now. I would take the machine off line , until I was sure about all of this, ..but then again, maybe you got it from some trusted source and do not need to worry. Maybe the source of it has some support or can help you as well. What kind of images did it contain ?

but I'm worried that a bunch of links were created that the system might still try to write to despite folder being deleted; I've heard about this sort of situation sometimes doing that.

Do you mean "symlinks" ? or what kind of links ?
Key words:

Code: Select all

How to locate all the symlinks on my linux system 

We already know what is Symlinks or Symbolic links or Soft links and how to find and delete broken Symlinks from our Linux system. Today, we are going to learn how to list Symlinks on Linux. If you have created some symlinks a long time ago and completely forget about them, this quick tip will help you to easily find them using "find" command.

You can try:

Code: Select all

# find / -type l 

It may be slow, depending on the size of your system. Or use the key words I show, copy/paste to a search engine, and read some of the tutorials on that. For now , I can't think of anything else.

[sickpig]

tmpfs 32G 245M 32G 1% /dev/shm

You got 64 gb RAM?
I want.

[LE_746F6D617A7A69]

but I'm worried that a bunch of links were created that the system might still try to write to despite folder being deleted; I've heard about this sort of situation sometimes doing that.

Gzip does not store any links in the archive, and so no links can be created on decompression.
According to the disk usage reported by df, the decompressed data took 845G-390G=455G, what means that the decompression speed would be about 455G/(10min*60secs) = 758MB/s -> this is impossible, unless You have *very* fast RAID/SSD. (and CPU, since decompression is running in a single thread/core)

So, a few questions needs to be answered:
- what is the type of that disk?
- Is the archive really that big?
- what filesystem do You have on top of LVM?
- did You fsck the filesystem?

[cuckooflew]

Curious here, but how do we know it was gzip ?

Mr. Lumbergh » 2020-08-26 20:39
I started unpacking a zip archive ----

I realize it could be, but do not see any where that the OP says it is gzip, that is why I am asking.

[LE_746F6D617A7A69]

Curious here, but how do we know it was gzip ?

Nah, I should say zip not gzip.
AFAIN none of zip and 7z compressors is storing the links, but some have the option to follow the links - but in such case the archive contains the file or a directory that the link is pointing to, but not the link itself.

[Mr. Lumbergh]

You can try:

Code: Select all

# find / -type l 

It may be slow, depending on the size of your system. Or use the key words I show, copy/paste to a search engine, and read some of the tutorials on that. For now , I can't think of anything else.

It was just a .zip.
I ran

Code: Select all

ls -lR / | grep ^l^C

and it terminated in about a second. Is there a way I can set that to pause on each page so I can take a look?
Thanks for the suggestion, it doesn't appear to have any runaway links being copied. I also didn't do anything as root when I unpacked it, just a right-click and "extract here."

[Mr. Lumbergh]

tmpfs 32G 245M 32G 1% /dev/shm

You got 64 gb RAM?
I want.

I can't lie, it is pretty cool.

[Mr. Lumbergh]

but I'm worried that a bunch of links were created that the system might still try to write to despite folder being deleted; I've heard about this sort of situation sometimes doing that.

Gzip does not store any links in the archive, and so no links can be created on decompression.
According to the disk usage reported by df, the decompressed data took 845G-390G=455G, what means that the decompression speed would be about 455G/(10min*60secs) = 758MB/s -> this is impossible, unless You have *very* fast RAID/SSD. (and CPU, since decompression is running in a single thread/core)

So, a few questions needs to be answered:
- what is the type of that disk?
- Is the archive really that big?
- what filesystem do You have on top of LVM?
- did You fsck the filesystem?

-It's a 1TB hybrid drive
-It should have topped out around 156, but did look like it was making multiple copies for some reason. I wonder if I accidentally instructed Ark to unpack everything to different paths, I used it to look at the contents first and some things were nested. I moved the zip archive only off to an external drive and unpacked it there and it only took the 156G.
-Ext 4
-Not yet, I'm typing this right now so I'll schedule that before I shut down.

[sickpig]

I can't lie, it is pretty cool.

oooh I would just run everything from a RAM tmpfs then. So cool.

[neuraleskimo]

-It should have topped out around 156, but did look like it was making multiple copies for some reason. I wonder if I accidentally instructed Ark to unpack everything to different paths, I used it to look at the contents first and some things were nested. I moved the zip archive only off to an external drive and unpacked it there and it only took the 156G.

The nesting you saw sounds interesting. I haven't used Ark in a long time, so I don't clearly recall the interface. Is it possible that you accidentally did a drag and copy of the root directory into the root directory (e.g., finger twitch)? As I write that, I am recalling my wife's method of backing up was to copy the contents of her home directory into a directory in her home folder. If that sounds tragically recursive. It is! Anyway, it has also been a long time since I looked at Zip file formats, but I think you may end up with multiple file entries to the same bytes. If that happens, then the size of the Zip won't increase much BUT the same data will be unzipped multiple times. If you are feeling like exploring this, give that a try. Otherwise, I don't think you have anything to worry about.

[Mr. Lumbergh]

The nesting you saw sounds interesting. I haven't used Ark in a long time, so I don't clearly recall the interface. Is it possible that you accidentally did a drag and copy of the root directory into the root directory (e.g., finger twitch)? As I write that, I am recalling my wife's method of backing up was to copy the contents of her home directory into a directory in her home folder. If that sounds tragically recursive. It is! Anyway, it has also been a long time since I looked at Zip file formats, but I think you may end up with multiple file entries to the same bytes. If that happens, then the size of the Zip won't increase much BUT the same data will be unzipped multiple times. If you are feeling like exploring this, give that a try. Otherwise, I don't think you have anything to worry about.

OK, thanks. I think I may have accidentally done exactly that, generate multiple copies of the same data by triggering multiple decompressions. It freaked me out a bit when I saw it, but I've been checking for new links and unusual disk activity the past couple days since and it seems OK.
I'll go ahead and close this one out, thank you everyone.