I am trying to replace my local development machine with Google Cloud Sheel. When running yarn on Cloud Shell, the system says I am out of space. But df tells me there is lots of space remaining (only 68% used on /home)
#cloudshell:~/***$ df
Filesystem 1K-blocks Used Available Use% Mounted on
overlay 62742040 43483680 19241976 70% /
tmpfs 65536 0 65536 0% /dev
tmpfs 8200748 0 8200748 0% /sys/fs/cgroup
/dev/disk/by-id/google-home-part1 5028480 3229288 1520716 68% /home
/dev/sda1 62742040 43483680 19241976 70% /root
/dev/root 2006736 1012260 994476 51% /lib/modules
shm 65536 0 65536 0% /dev/shm
tmpfs 8200748 904 8199844 1% /google/host/var/run
user#cloudshell:~/**$ pwd
/home/user/***
user#cloudshell:~/***$ mkdir test
mkdir: cannot create directory ‘test’: No space left on device
Am I missing something? Why does the system say out of space when there is 32% left?
According to the Cloud Shell documentation:
Cloud Shell provisions 5 GB of free persistent disk storage mounted as
your $HOME directory on the virtual machine instance.
...
If you encounter a no space left on device error, you'll need to remove files from your home directory using the Cloud Shell terminal to free up space.
So it is possible that when it reaches a certain threshold of disk usage that message will pop up.
Related
I deployed using kolla-ansible 5.0.0.
I used fdisk to create a new xfs sda4 primary partition with size of 1.7 TB and then I created the rings following this documentation for kolla-ansible:
https://github.com/openstack/kolla-ansible/blob/master/doc/source/reference/swift-guide.rst
After I deployed, swift seems to work fine. However /dev/sda4 is not mounted to /srv/node/sda4 and all of swift's files or data gets put in root.
output of fdisk -l showing my sda4 disk partition I want swift to use:
[root#openstackstorage1 swift]# fdisk -l
Disk /dev/sda: 1999.8 GB, 1999844147200 bytes, 3905945600 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk label type: dos
Disk identifier: 0x000c22f6
Device Boot Start End Blocks Id System
/dev/sda1 * 2048 718847 358400 83 Linux
/dev/sda2 718848 2815999 1048576 82 Linux swap / Solaris
/dev/sda3 2816000 209663999 103424000 8e Linux LVM
/dev/sda4 209664000 3905945599 1848140800 83 Linux
WARNING: fdisk GPT support is currently new, and therefore in an experimental phase. Use at your own discretion.
output of df -h
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/rootvg01-lv_root 98G 3.4G 95G 4% /
devtmpfs 3.9G 0 3.9G 0% /dev
tmpfs 3.9G 0 3.9G 0% /dev/shm
tmpfs 3.9G 9.0M 3.9G 1% /run
tmpfs 3.9G 0 3.9G 0% /sys/fs/cgroup
/dev/mapper/openstackvg01-lv_openstackstorage 2.8T 75G 2.7T 3% /var/lib/docker
/dev/sda1 347M 183M 165M 53% /boot
tmpfs 782M 0 782M 0% /run/user/0
this output of df -h /srv/node/sda4 shows a logical volume of root disk is mounted on /srv/node/sda4.
[root#openstackstorage1 swift]# df -h /srv/node/sda4/
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/rootvg01-lv_root 98G 3.4G 95G 4% /
but shouldn't my /dev/sda4 partition I made be mount to /srv/node/sda4 ?
Not sure what I did wrong and need guidance please
The reason this was not working is cause my /dev/sda4 was not an xfs filesystem......I just had to run mkfs.xfs –f –I size=1024 –L sda4 /dev/sda4 on my partition I created and then I mount it myself mount -t xfs -L sda4 /srv/node/sda4
I then had to restart all swift services and now all swift files and data are being stored in /srv/node/sda4 where /dev/sda4 is mounted.
I'm running a docker container that seems to have insufficient memory and I'm not sure how to solve this problem.
I'm essentially running a program on this docker container that downloads an image into tmpfs, performs some operations, deletes the the image and returns a result. However, it seems like I'm running into images that are too large to store in my current docker tmpfs. Below is the output of the linux df command while inside the container:
Filesystem Size Used Avail Use% Mounted on
overlay 63G 11G 50G 18% /
tmpfs 64M 0 64M 0% /dev
tmpfs 6.9G 0 6.9G 0% /sys/fs/cgroup
/dev/sda1 63G 11G 50G 18% /etc/hosts
shm 64M 4.0K 64M 1% /dev/shm
tmpfs 6.9G 0 6.9G 0% /sys/firmware
I've tried expanding docker's memory (hence the huge values on two of the tmpfs's) but I'm still running into this problem.
I guess I have a couple of questions:
1) what is the difference between the 3 separate tmpfs filesystems? Why do they exist?
2) Presumably I need to expand the first tmpfs size (the small one) -- how would I go about doing that?
Finally, some relevant system information:
OS -- OSX
Docker version -- Docker version 17.09.0-ce, build afdb6d4
Let me know if there's other stuff you need to know!
Thanks everyone.
Okay, ultimately figured out the answer. My original two questions were kind of off base.
Essentially, my docker instance didn't have enough memory -- the tmpfs files were red herrings. I ended up needing to pass in a --shm-size="4096m" argument to my docker start command (increased memory to 4096 megabytes) in order to allow my function to properly execute. Hope this helps someone down the road!
Also, for google purpose, the exact error I was getting was There is not enough space available on the shmfs/tmpfs file system. relating to Abbyy FineReader
If you are using Kubernetes, then you need sufficient space in /dev/shm.
In my case, there wasnt enough space in /dev/shm hence Abbyy would bail out before extracting Meta-images. After giving /dev/shm a volume mount, it worked fine. Hope this helps!
I am a total noob on this one. I have a google cloud SUSE instance which is running a VM image. I am trying to install a package but I think it's running out of space.
What I want to do is to assign some of the 120G space to my /dev/sda1 partition. I have read the google's guide but I am not sure which section should I be following.
>df -h
Filesystem Size Used Avail Use% Mounted on
devtmpfs 13G 0 13G 0% /dev
tmpfs 13G 0 13G 0% /dev/shm
tmpfs 13G 9.7M 13G 1% /run
tmpfs 13G 0 13G 0% /sys/fs/cgroup
/dev/sda1 36G 34G 0 100% /
tmpfs 2.6G 0 2.6G 0% /run/user/490
tmpfs 2.6G 0 2.6G 0% /run/user/1004
tmpfs 2.6G 0 2.6G 0% /run/user/1006
>sudo lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 0 120G 0 disk
└─sda1 8:1 0 36G 0 part /
Without reboot increase boot size in GCP cloud VM
Check first disk usage using df -h if usage of /dev/sda1 more than 80% it's dangerous.
Update disk size on the fly
Increase disk size from console first
SSH inside VM : sudo growpart /dev/sda 1
Resize your file system : sudo resize2fs /dev/sda1
Verify : df -h
Increase the size of existing persistent disk:
Login to Google Cloud Platform
Goto Compute Engine -> Disks
Locate your VM's boot disk(default disk), open it
Click Edit
Enter a new size, please note that you won't be able to decrease this size later.
Reboot your VM, you should be able to see new size of disk.
This is just an addition to Prateeks answer. After changing the size, you need to run (linux only) to reboot:
sudo reboot
Give it some time, close your console if you get no response. Then run df again to see the new size.
Super late to the party but using sudo growpart /dev/sda 1 worked for me
I changed size of my persistent disk from 10GB to 20GB.
Screenshot
Now when I run df command in my server, I can still see only 10GB space.
user#edudrona-prod-vm:~$ df
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/sda1 10186040 6755924 2889652 71% /
udev 10240 0 10240 0% /dev
tmpfs 1535964 8528 1527436 1% /run
tmpfs 3839908 0 3839908 0% /dev/shm
tmpfs 5120 0 5120 0% /run/lock
tmpfs 3839908 0 3839908 0% /sys/fs/cgroup
tmpfs 767984 0 767984 0% /run/user/1003
I am just running simple Wordpress site using Bitnami. Except from changing 10GB to 20GB, I did not make any change to increase disk space. Do I have to play around with settings anywhere else as well?
Update:
I got following output from resize2fs command:
user#edudrona-prod-vm:~$ sudo resize2fs /dev/sda1
resize2fs 1.42.12 (29-Aug-2014)
The filesystem is already 2620416 (4k) blocks long. Nothing to do!
Take a look at the documentation here.
resize2fs alone is not sufficient because what it does is resizing to fill the extents of the carrier partition, but your /dev/sda1 is still the old size. You need to resize that first. On some operating systems the whole root partition upsizing is done automatically on boot, so try rebooting to see if just that does the trick. Otherwise, you'll need to follow the manual steps. Be careful and make sure to back things up first.
My oracle application test instance is down, When I browse through the Unix server, I couldn’t find any files in the mount point,U01 U06 or U10, when I put BDF command it shows the following
$ bdf
Filesystem kbytes used avail %used Mounted on
/dev/vg00/lvol3 204800 35571 158662 18% /
/dev/vg00/lvol1 299157 38506 230735 14% /stand
/dev/vg00/lvol8 1392640 1261068 123620 91% /var
/dev/vg00/lvol7 1327104 825170 470631 64% /usr
/dev/vg00/lvol4 716800 385891 310746 55% /tmp
/dev/vg00/lvol6 872448 814943 53936 94% /opt
/dev/vg00/lvolssh 32768 13243 18306 42% /opt/openssh
/dev/vg00/lvol5 204800 187397 16334 92% /home
/dev/vg00/lvolback 512000 472879 36704 93% /backup
dg-ora04:/dgora03_u10
204800 167088 35416 83% /u10
dg-ora04:/dgora03_u06
204800 167088 35416 83% /u06
dg-ora04:/dgora03_u01
204800 167088 35416 83% /u01
Please let me Know why I cant see any files inside the mount points.
If you see no files, consider running fsck on the filesystem. The file metadata has a problem. Also, the lost+found directory may have lots of those files listed in it after fsck runs.
Are these file devices presented on a lun? You may have to play with the volume manager to get things back on track.
Plus, the root cause of your problem is probably: The files look like they are NFS mounts - which, BTW, is a colossal non-no as far as oracle is concerned. Even with NFS 4, you can get into a lot of pain using remote mounted filesystems with oracle file I/O drivers.