Hi,

/ filesystem reached 93%, and space need to be cleared.

Filesystem Size Used Avail Use% Mounted on
/dev/mapper/os-root 7.8G 6.9G 548M 93% /
/dev/mapper/os-var 7.8G 574M 6.8G 8% /var
/dev/mapper/data-export
59G 30G 26G 54% /export
/dev/sda1 99M 36M 59M 38% /boot
tmpfs 12G 0 12G 0% /dev/shm
/dev/sdb1 341M 80M 261M 24% /ocr_shared/ocr_1
/dev/sdb2 341M 80M 261M 24% /ocr_shared/ocr_2
/dev/sdb3 341M 90M 252M 27% /ocr_shared/vote_1
/dev/sdb5 341M 90M 252M 27% /ocr_shared/vote_2
/dev/sdb6 341M 90M 252M 27% /ocr_shared/vote_3
/dev/sdb7 343M 74M 269M 22% /ocr_shared/spfiles
/dev/sdal1 1.2T 17G 1.2T 2% /recovery_area
/dev/sdam1 10G 6.2G 3.9G 62% /log
/dev/sdt1 50G 2.3G 48G 5% /sdp_bd/SDPIE01/data1
/dev/sdt2 50G 1.1G 49G 3% /sdp_bd/SDPIE01/index1


what can be deleted...?

Any commands to find the files that can be deleted ...please...?

Can we extend the root filesystem size ?

what's filling /? Post the output of

/var or /home is probably filling, and you can mount them on another partition. I don't know the policy you have on logs, so old logs can go if you don't need them. They can certainly be backed up and then deleted. If /lost+found is filling, your disk is bad (usually).

First place to look would be /tmp since it isn't a separate filesystem on your server it is part of /.

Files in /tmp are supposed to be temporary. If the file is older than a day and NOT CURRENTLY IN USE it generally safe to delete. You can determine if a file is in use by running "lsof <filename>" against the filename of the file you're interested in. I'd look for largest files first then smaller ones. Also check out any subdirectories in /tmp as often they contain large files when the directory itself is only showing something like 4096 bytes.

Another place to look would often be /var/tmp or /var/log but in your case /var IS a separate filesystem so files in those two directories are NOT part of /.

Typically if I'm not sure what is eating up space I'll do something like:
cd /
du -sxk * |sort -n
That will show you largest users of space at the bottom and the smallest at the top.
You should ignore anything that appears in this list that is a separate filesystem (e.g. /var, /ocr_shared/ocr_1, /boot etc...). The rest will be part of the filesystem.

Once you find subdirectories that are large (assuming you don't find individual files) you can cd to that directory then run the du command again to drill down on it.

What is "safe" to delete depends a lot on what it is and when it is needed. For example you'll find /usr takes up a lot of space but things like /usr/lib, /usr/bin should NOT be mucked with generally. On the other hand if you logs going into something like /usr/local/logs then files there might be "safe" to address so long as NOT CURRENTLY IN USE.

you might want to reinstall
that 7.8 gig partition is ALWAYS going to cause some problems

It is a bit too small
the very bare minimum size is normally 9 Gig
With 15 to 20 Gig preferred

normally the log files end up eating space
set cron to remove old files in/var/log/??????
and to remove old /tmp files( any older that two days or if still in use, sense before the last reboot)

also is there a NEED for all those 341 MEG partitions sdb1 through 7

you might want to use a LVM for this unnamed operating system

You seem to have an almost unused 2TB disk on /dev/sda, and, as noted, a VERY small amount of space for your root fs on /dev/sdb. (And, why is it on /dev/mapper? There's not much point in VM files for a one-disk set-up, and it doesn't look like you're using mdadm. What distribution are you using? From you handle, perhaps Red Hat? I use Fedora - Red Hat's "testing" distribution, and it defaults to using LVM for its install so they can get more testing of that system, but - if you don't have a dozen or so drives on your system - my personal opinion is that you should not use that default.)

On the other hand, if you ARE using LVM, you can fairly easily expand your 8GB partition by adding a new partition - maybe from you /dev/sda - to your (logical) root file system.

I disagree on the comments about LVM. Using it even on a single disk solution is good because it gets around limitations on number of partitions and especially on the amount of effort required if you want to add/resize partitions where others already exist. LVM allows you to add LVs or resize upward on the fly. (You can even resize downward but that takes a bit more care.)

The comments about the /recovery area aren't quite valid either. The space may appear to be underutilized but depending on how it is used may not always be avaialble. If for example this is something being used for Oracle Flash Recovery Area the utilization of the space can change quite drastically depending on the operations occurring in the DB.

It also isn't "available" space - it would have to be reclaimed (reduce the LV) then made "available" to add to other LVs.

However a good question was raised about the size of / itself. Based on this is the OP should show:
a) fdisk -l
b) vgdisplay -v

It may indicate whether there is other unused space that could be allocated to / (or better yet to putting things in their own filesystems like /tmp).

Install bleachbit and remove unnecessary files.

with the / partition only 7.8 gig

that will not do mush good

I fear the OP has been kidnapped. Otherwise surely we'd have gotten a response by now.

Thanks ALL for your response to my query.

Your Help is highly appreciable.

ThaNks.
APARNA.