Total files size larger than filesystem size?

[siva0123]

Friends,

I've got a interesting problem.

I've got a filesystem whose size is only 32 gb and bdf shows that correctly and also reports that used space is around 28 GB and the filesystem is 92 % full.

But.. When i do a ls -al on the filesystem and calculate the total size of all the files it shows up as 37 GB :-( How can that be possible ??? if the filesystem size it self is only 32 GB


Thanks,
Siva

[James R. Ferguson]

Hi Siva:

The first question I'd ask you is if you have *excluded* hard-linked files from your summation? For example, '/sbin/vg*' files are all hardlinks of one binary.

Regards!

...JRF...

[Steve Steel]

Hi


Which tool did you use to add

rounding errors if a lot of files


Or
sparse files which show differently

With all respect
to err is human

If the computer is happy then try to be happy to

Steve Steel

[Calandrello]

Friend this really this seeming to be links.

[siva0123]

Dear JRF,

Infact the filesystem had only ten DB files and there is no harlinked files.

Aslo i see the following in further investigation:

[taaput01:root:data04] # fstyp -v /dev/vg05/lvol26
vxfs
version: 4
f_bsize: 8192
f_frsize: 4096
f_blocks: 7815168
f_bfree: 599451
f_bavail: 590341
f_files: 145792
f_ffree: 149856
f_favail: 149856
f_fsid: 1074069530
f_basetype: vxfs
f_namemax: 254
f_magic: a501fcf5
f_featurebits: 0
f_flag: 16
f_fsindex: 7
f_size: 7815168

Filesystem size = ((size*bsize)/1024)/1024

===>((7815168*8192)/1024)/1024) == 61056 MB


--- Logical volumes ---
LV Name /dev/vg05/lvol26
VG Name /dev/vg05
LV Permission read/write
LV Status available/syncd
Mirror copies 0
Consistency Recovery MWC
Schedule parallel
LV Size (Mbytes) 30528 ====> Size of LV
Current LE 477
Allocated PE 477
Stripes 0
Stripe Size (Kbytes) 0
Bad block on
Allocation strict
IO Timeout (Seconds) default


Definitely the LV Size and the FS size are different , so i hope i've only the following options.

1. Reduce the FS size equal to LV size

or

2. Increase the LV size to FS size

or

3. Create a new fs from scratch and restore.


But Can anybody help me in guiding how could have this happened???

Thanks,
Siva

[A. Clay Stephenson]

It is quite possible to overcommit a filesystem just as airlines do with passendger ticketing. The principle reasons are: 1) sparse files 2) multiple links to the same file.

Consider writing 1 byte at offset 0 of a file and then immediately seeking to offset 10,000,000 and writing one more byte. You have actually written 2 bytes of data but ls -l would indicate the size of the file as 10,000,000 bytes. However, to the filesystem (du, bdf) only two blocks have been allocated. When read() is called, the missing bytes are silently filled in with NUL's.

If there are multiple links to the same physical file (or symbolic links to another filesystem) then depending upon how you are adding up your totals, you could be counting the same file multiple times.

[James R. Ferguson · Accepted solution]

Hi (again) Siva:

You need to compute usign the 'f_frsize' value which is the filesystem's actual block size. There is nothing wrong with your filesystem.

As mentioned, it would appear that 'sparse' files have inflated your view of the size of the filesystem. Sparse files are commonly found associated with databases.

Do this:

# perl -le 'open(FH,">","/tmp/sparsef") or die;seek(FH,10000000,0);print FH "eof"'

# ls -l /tmp/sparsef
-rw-r----- 1 root sys 10000004 Dec 4 08:49 /tmp/sparsef

# du -k /tmp/sparsef
8 /tmp/sparsef

The blocks for the file are not yet allocated, but 'ls' shows the file's size as if they would be, or when they will be.

Regards!

...JRF...

[Calandrello]

Friend
the best option would be to increase filesystem it to reduce is not a good option therefore can lead loses it of data. to increase file they system uses the command lvextend -L (so great total that lvol must be in MB ) /dev/lvname
in case that you I do not have jfsonline, I disassemble lvol and I execute extendfs /dev/vg00/rlvol1

[siva0123]

Hi Clay , JRF

Thanks for explaining me about these sparse file..

Now i've a problem.

We are in the process of replcating a database and we have created all the filesystem layouts based on the sizes calculated from the bdf and du -k outputs.

But when we copy all the files from these filesystem we are not able to do so and it fails just because it is looking for 37 GB where as we have created the Filesystem size as 30 GB only based on the original bdf o/p.


Now is there no other way to overcome this sparse files ?

Should i 've to trust only the summation of the total files size to replicate the filesystem ???


Thanks,
Siva

[James R. Ferguson]

Hi Siva:

One of the not-so-nice properties of sparse files is that they expand (i.e their blocks are filled with zeros) when you use 'cp' to copy them.

One of the best ways to avoid this is to use 'fbackup' and 'frecover'. For example, to copy from one directory to another, and *not* expand the sparse files:

# cd /srcdir && fbackup -i . -f - | (cd /dstdir; frecover -Xsrf -)

Regards!

...JRF...

[siva0123]

Experts ,

Any suggestions??

Thanks,
Siva

[Calandrello]

Friend
for you copy you can use the command:
cd ; tar cf - . | (cd ; tar xfp -)
with this flag it anger to copy all links

[James R. Ferguson]

Hi Siva:

You also asked if you can trust the summartion of the total file sizes when a filesystem is replicated.

First, assuming that you have not inflated sparse riles as I showed in my post above, the answer is still generally "no". Directories consume space, too, but when files are deleted from their parent directory that space is not freed and returned as available space.

Copying a directroy and its files to a new directory will often result in a smaller directory size, although if done correctly the *files* within both directories will be the same size.

You can always compare before and after 'cksum's for each file copies. They will be identical unless the file was changing during the time of its copy or if some other interruption occured.

Regards!

...JRF...

[A. Clay Stephenson]

You should note that even cksum cannot identify sparse files. The read operation silently fills in the missing data with 0's. If it worked any other way, data would be corrupt. The only standard HP-UX tool that will preserve sparse files is fbackup/frecover and actually it's frecover that does the real work when the -s option is used. What really happens is that when frecover sees many consecutive zeroes, it writes a single 0, does an lseek() and then writes the last zero. Even in this case, the files may not be restored exactly as they were becuase the number of NUL's actually written may differ BUT the files will be equivalent in actual data content.

In any event, you should really expand your LVOL and filesystem up to the maximum size. With large sparse files present, you are really an accident waiting to happen.

[siva0123]

JRF, Clay ,

Thanks again for all your suggestions.

I would try the fbackup option .

Thanks,
Siva