Tag Info

New answers tagged

1

But what I'd like to know is whether or not all of my files on it are fine. Ext3 has no functionality for this, but questions like that come up in IT-security as well. The solution there is to create a list of hash-sums (i.e. practically unforgeable checksums) over the files and its meta-data and compare these stored sums with the actual sums at times ...


0

I couldn't add a comment. So I am putting it here. Apart from the filesystem test, may be you can also you the Disk Utility to run SMART test on the disk and verify the health of the disk.


2

Is there some way, either general or specific, that I can verify that none of the files on my filesystem were damaged? Without copies of the files to refer to, I think this is impossible. Have you looked in /lost+found? If anything was corrupted into pieces, those pieces will be left there by fsck. I have seen this happen before too, and as far as I ...


5

After looking at the code for various utilities and the kernel code for some time, it does seem that what @Hauke suggested is true - whether a filesystem is ext2/ext3/ext4 is purely defined by the options that are enabled. From the Wikipedia page on ext4: Backward compatibility ext4 is backward compatible with ext3 and ext2, making it possible to ...


1

Not a direct answer but in looking at the output of tune2fs -l ... for each type of filesystem shows the following differences. Filesystem features EXT2 Filesystem features: ext_attr resize_inode dir_index filetype sparse_super EXT3 Filesystem features: has_journal ext_attr resize_inode dir_index filetype needs_recovery sparse_super ...


1

One likely reason for running out of inodes is that a large number of files has accumulated in a particular directory for whatever reason. You could check the usual suspects, eg /tmp, /var/tmp, /var/log etc. If you don't find anything, here is a command that I have cobbled together to list the top 50 directories in the filesystem containing the most ...


1

Looking at the comments others have helped you diagnose you're out of inodes. If you need to make a few available so you can get some basic access back to your system then you could delete the following files on a CentOS 5 install, assuming you can live without them. Example $ sudo rm -fr /var/log/*.[1-9]?(.gz) This will remove any of the previously ...


1

Why? Because no one has written a tool that does it. And that's probably because it's a not entirely trivial change to the filesystem metadata. There are other issues like this; for example you can't resize ext4 to >16TB. That needs 64bit structures which aren't used by default. Same with other filesystems, for example you can't shrink XFS. None of these ...



Top 50 recent answers are included