I have a directory I’m archiving:
$ du -sh oldcode
1400848
$ tar cf oldcode.tar oldcode
So the directory is 1.4gb. The file is significantly smaller, though:
$ ls -l oldcode.tar
-rw-r--r-- 1 ieure ieure 940339200 2002-01-30 10:33 oldcode.tar
Only 897mb. It’s not compressed in any way:
$ file oldcode.tar
oldcode.tar: POSIX tar archive
Why is the tar file smaller than its contents?
You get a difference because of the way the filesystem works.
In a nutshell your disk is made out of clusters. Each cluster has a fixed size of - let's say - 4 kilobytes. If you store a 1kb file in such a cluster 3kb will be unused. The exact details vary with the kind of file-system that you use, but most file-systems work that way.
3kb wasted space is not much for a single file, but if you have lots of very small files the waste can become a significant part of the disk usage.
Inside the tar-archive the files are not stored in clusters but one after another. That's where the difference comes from.
Having no knowledge of what tar you're using or what sort of Unix system you're using, here's my guess: oldcode contains numerous smaller files, which when by themselves use disk space inefficiently, since disk space is allocated by some sort of block, rather than byte by byte. In the tar file, they're concatenated, and make maximum use of the disk space they're assigned.
This has something to do with the blocksize of your filesystem. man 1 du on MacOSX 10.5.6 states:
The du utility displays the file system block usage for each file argument and for each directory in the file hierarchy rooted in each directory argument. If no file is specified, the block usage of the hierarchy rooted in the current directory is displayed.
[mirko#borg foo]$ ls -la
total 0
drwxr-xr-x 2 mirko wheel 68 Jan 30 21:20 .
drwxrwxrwt 10 root wheel 340 Jan 30 21:16 ..
[mirko#borg foo]$ du -sh
0B .
[mirko#borg foo]$ touch foo
[mirko#borg foo]$ ls -la
total 0
drwxr-xr-x 3 mirko wheel 102 Jan 30 21:20 .
drwxrwxrwt 10 root wheel 340 Jan 30 21:16 ..
-rw-r--r-- 1 mirko wheel 0 Jan 30 21:20 foo
[mirko#borg foo]$ du -sh
0B .
[mirko#borg foo]$ echo 1 > foo
[mirko#borg foo]$ ls -la
total 8
drwxr-xr-x 3 mirko wheel 102 Jan 30 21:20 .
drwxrwxrwt 10 root wheel 340 Jan 30 21:16 ..
-rw-r--r-- 1 mirko wheel 2 Jan 30 21:20 foo
[mirko#borg foo]$ du -sh
4.0K .
As you see even a file of 2 bytes takes a whole block of 4kb. There are some filesystems which avoid this waste of space by block suballocation.
There are 2 possibilities.
Small files
Most likely, it isn't smaller than its contents. As Nils Pipenbrinck wrote, du displays the amount of space the filesystem allocates, which since files are stored in filesystem blocks is more than the logical size of the file.
To view the logical size of the file, use du --apparent-size. In this case, the result should be smaller than the tar file.
Sparse files
Tar files can store sparse files. If the tarball was created using --sparse, the holes in the sparse files will be recorded, so the tarball could be smaller than the logical size of the files.
If the sparseness information in your extracted copy was somehow lost (e.g. if you extracted the tarball onto a filesystem that doesn't support sparse files, or if it was zipped and then unzipped, etc.), then df will report the expanded size.
du counts disk blocks, not file size duder.
Related
For those reaching here; Unfortunately I could not recover the data, after various tries and reproducing the problem it was too costy to keep trying, so we just used a past backup to recreate the information needed
A human error broke an 150G UFS filesystem (Solaris).
When trying to do a backup of the filesytem (c0t0d0s3) the ufsdump(1M) hasn't been correctly used.
I will explain the background that led to this ...
The admin used:
# ufsdump 0f /dev/dsk/c0t0d0s3 > output_1
root#ats-br000432 # ufsdump 0f /dev/dsk/c0t0d0s3 > output_1
Usage: ufsdump [0123456789fustdWwnNDCcbavloS [argument]] filesystem
This is a bad usage, so it created a file called output_1 with 0 bytes:
# ls -la output_1
-rw-r--r-- 1 root root 0 abr 12 14:12 output_1
Then, the syntax used was:
# ufsdump 0f /dev/rdsk/c0t0d0s3 output_1
Which wrote that 0 bytes file output_1 to /dev/rdsk/c0t0d0s3 - which was the partition slice
Now, interestingly, due to being a 0 bytes file, we thought that this would cause no harm to the filesystem, but it did.
When trying to ls in the mountpoint, the partition claimed there was an I/O error, when umounting and mounting again, the filesystem showed no contents, but the disk space was still showing as used just like it was previously.
I assume, at some point, the filesystem 'header' was affected, right? Or was it the slice information?
A small fsck try brings up this:
** /dev/rdsk/c0t0d0s3
** Last Mounted on /database
** Phase 1 - Check Blocks and Sizes
INCORRECT DISK BLOCK COUNT I=11 (400 should be 208)
CORRECT?
Disk block count / I=11
this seems that the command broke filesystem information regarding its own contents, right?
When we tried to fsck -y -F ufs /dev/dsk.. various files have been recovered, but not the dbf files we are after (which are GB sized)
What can be done now? Should I try every superblock information from newfs -N ?
EDIT: new information regarding partition
newfs output showing superblock information
# newfs -N /dev/rdsk/c0t0d0s3
Warning: 2826 sector(s) in last cylinder unallocated
/dev/rdsk/c0t0d0s3: 265104630 sectors in 43149 cylinders of 48 tracks, 128 sectors
129445,6MB in 2697 cyl groups (16 c/g, 48,00MB/g, 5824 i/g)
super-block backups (for fsck -F ufs -o b=#) at:
98464, 196896, 295328, 393760, 492192, 590624, 689056, 787488, 885920,
Initializing cylinder groups:
.....................................................
super-block backups for last 10 cylinder groups at:
264150944, 264241184, 264339616, 264438048, 264536480, 264634912, 264733344,
264831776, 264930208, 265028640
When I do ls -l I get
-rw-r--r-- 1 jboss admin **26644936** Sep 1 21:23 MyBig.war
How do I print it as below
-rw-r--r-- 1 jboss admin **26,644,936** Sep 1 21:23 MyBig.war
The proper way to format ls output is to specify BLOCK_SIZE.
Saying:
BLOCK_SIZE="'1" ls -l
would achieve your desired result.
Quoting from the above link:
Some GNU programs (at least df, du, and ls) display sizes in “blocks”.
You can adjust the block size and method of display to make sizes
easier to read.
A block size specification preceded by ‘'’ causes output sizes to be
displayed with thousands separators.
Using sed:
$ ls_output='-rw-r--r-- 1 jboss admin 26644936 Sep 1 21:23 MyBig.war'
$ echo $ls_output | sed -e :a -e 's/\(.*[0-9]\)\([0-9]\{3\}\)/\1,\2/;ta'
-rw-r--r-- 1 jboss admin 26,644,936 Sep 1 21:23 MyBig.war
Above sed command repeatedly replace the last 4 digits #### with #,###.
-e :a: Make a label named a for t command.
ta: Jump to a if substitution was successful.
I have partition structure like :
$ df
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/sda6 51606140 16939248 34142692 34% /
/dev/sda5 495844 72969 397275 16% /boot
/dev/sda7 113022648 57515608 49765728 50% /home
/dev/sda8 113022648 57515608 49765728 4% /mnt
while parsing directories content using readdir() - how to find out which file resides on what device?
readdir() invoked from root directory and parses the file name and prints its size.
like from device : /dev/sda6 and list the filenames under that partition.
When it reads contents from /home - it should display reading content from /dev/sda7 and list filenames
Please let me know,if you need more details/info
you can just do
df <file_name>
that will give you the device and partition for the particuar file
There is a st_dev member in struct stat, it should uniquely identify one partition.
Example in bash:
stat ~/.vimrc
File: `/home2//leonard/.vimrc' -> `local-priv/vimrc'
Size: 16 Blocks: 0 IO Block: 4096 symbolic link
Device: 802h/2050d Inode: 6818899 Links: 1
Access: (0777/lrwxrwxrwx) Uid: ( 1024/ leonard) Gid: ( 1024/ leonard)
Access: 2012-06-22 16:36:45.341371003 +0300
Modify: 2012-06-22 16:36:45.341371003 +0300
Change: 2012-06-22 16:36:45.341371003 +0300
The stat utility does no additional magic. Here is strace -vvv output:
lstat64("/home2//leonard/.vimrc", {st_dev=makedev(8, 2), st_ino=6818899, st_mode=S_IFLNK|0777, st_nlink=1, st_uid=1024, st_gid=1024, st_blksize=4096, st_blocks=0, st_size=16, st_atime=2012/06/22-16:36:45, st_mtime=2012/06/22-16:36:45, st_ctime=2012/06/22-16:36:45}) = 0
0x0802 is major 8(sd) partition 2, so /dev/sda2
In order to map this to actual partitions you can iterate /proc/mounts and stat all the devices (first column). The contents of /proc/mounts is just like the output of mount(1) except it comes directly from the kernel. Some distros symlink /etc/mtab to /proc/mounts.
Or you can parse /proc/partitions:
$ cat /proc/partitions
major minor #blocks name
8 0 976762584 sda
8 1 3998720 sda1
8 2 972762112 sda2
Of course /dev/sda might not actually exist, the device could be using a long udev name like /dev/disk/by-uuid/c4181217-a753-4cf3-b61d-190ee3981a3f. Major/Minor numbers should be a reliable unique identifier of a partition.
When you do this:
cp file1 file2
(file2 already exists)
What actually happens behind the scene?
1) Does the content of file1 actually get copied to file2?
2) Or is a new file created with the name file2 (overriding the old one) which has same content of file1?
1) Since you're using "cp", I assume the OS is Linux.
2) On Linux, a "file" is referenced by "inodes". Here are two example files:
$ ls -li 1 2
245728 -rw-r--r-- 1 paulsm users 8 Aug 14 14:52 1
245729 -rw-r--r-- 1 paulsm users 8 Aug 14 14:52 2
$ cat 1
Hello 1
$ cat 2
Hello 2
3) Here is the result after "cp"
$ cp 1 2
$ ls -li 1 2
245728 -rw-r--r-- 1 paulsm users 8 Aug 14 14:52 1
245729 -rw-r--r-- 1 paulsm users 8 Aug 14 14:55 2
$ cat 2
Hello 1
You see:
a) the contents of "1" completely replace "2"
b) there is no "new file" - the inode for "2" remains unchanged from before the copy
c) the file date is changed along with the file contents
'Hope that helps .. PSM
Usually the first. Both an index-entry as well as the file's data are written.
Yet it would help to know on what (file-)system you are (guessing linux flavour).
You would probably be aware if you were creating a junction point or symbolic/hard LINK.
Think of it like this:
Hardlink is a pointer/name, that points to a data; i.e. it's just an alternative filename; it has same inode number as the file it was created from.
Copy obviously, copy of the data; point to a different direction that file it was copyed from; has different inode number.
Also difference is in system calls, but that`s somewhat deep-diving into issue
Ok, I have been working with Solaris for a 10+ years, and have never seen this...
I have a directory listing which includes both a file and subdirectory with the same name:
-rw-r--r-- 1 root other 15922214 Nov 29 2006 msheehan
drwxrwxrwx 12 msheehan sysadmin 2048 Mar 25 15:39 msheehan
I use file to discover contents of the file, and I get:
bash-2.03# file msheehan
msheehan: directory
bash-2.03# file msh*
msheehan: ascii text
msheehan: directory
I am not worried about the file, but I want to keep the directory, so I try rm:
bash-2.03# rm msheehan
rm: msheehan is a directory
So here is my two part question:
What's up with this?
How do I carefully delete the file?
Jonathan
Edit:
Thanks for the answers guys, both (so far) were helpful, but piping the listing to an editor did the trick, ala:
bash-2.03# ls -l > jb.txt
bash-2.03# vi jb.txt
Which contained:
-rw-r--r-- 1 root other 15922214 Nov 29 2006 msheehab^?n
drwxrwxrwx 12 msheehan sysadmin 2048 Mar 25 15:39 msheehan
Always be careful with the backspace key!
I would guess that these are in fact two different filenames that "look" the same, as the command file was able to distinguish them when the shell passed the expanded versions of the name in. Try piping ls into od or another hex/octal dump utility to see if they really have the same name, or if there are non-printing characters involved.
I'm wondering what could cause this. Aside from filesystem bugs, it could be caused by a non-ascii chararacter that got through somehow. In that case, use another language with easier string semantics to do the operation.
It would be interesting to see what would be the output of this ruby snippet:
ruby -e 'puts Dir["msheehan*"].inspect'
You can delete using the iNode
If you use the "-i" option in "ls"
$ ls -li
total 1
20801 -rw-r--r-- 1 root root 0 2010-11-08 01:55 a?
20802 -rw-r--r-- 1 root root 0 2010-11-08 01:55 a\?
$ find . -inum 20802 -exec rm {} \;
$ ls -li
total 1
20801 -rw-r--r-- 1 root root 0 2010-11-08 01:55 a?
I've an example (in Spanish) how you can delete a file using then iNode on Solaris
http://sparcki.blogspot.com/2010/03/como-eliminar-archivos-utilizando-su.html
Urko,
And a quick answer to part 2 of my own question...
I would imagine I could rename the directory, delete the file, and rename the directory back to it's original again.
... I would still be interested to see what other people come up with.
JB
I suspect that one of them has a strange character in the name. You could try using the shell wildcard expansion to see that: type
cat msh*
and press the wildcard expansion key (in my shell it's Ctrl-X *). You should get two names listed, perhaps one of which has an escape character in it.
To see if there are special characters in your file, Try the -b or -q options to ls,
assuming solaris 8 has those options.
As another solution to deleting the file you can bring up the graphical file browser
(gasp!) and drag and drop the unwanted file to the trash.
Another solution might be to move the one file to a different name (the one without the unknown special character), then delete the special character directory name with wildcards.
mv msheehan temp
rm mshee*
mv temp msheehan
Of course, you want to be sure that only the file you want to delete matches the wildcard.
And, for your particular case, since one was a directory and the other a file, this command might have solved it all:
rmdir msheeha*
One quick-and-easy way to see non-printing characters and whitespace is to pipe the output through cat -vet, e.g.:
# ls -l | cat -vet
Nice and easy to remember!
For part 2, since one name contains two extra characters, you can use:
mv sheehan abc
mv sheeha??n xyz
Once you've done that, you've got sane file names again, that you can fix up as you need.