Tag Info

New answers tagged

1

The used space reported by df is reserved space. This reserved space is used by ext filesystems to prevent data fragmentation as well as to allow critical applications such as syslog to continue functioning when the disk is "full". You can view information about the reserved space using the tune2fs command: # tune2fs -l /dev/mapper/newvg-root tune2fs ...


2

The data loose most possible due controller write operation failure to disk, while its possible that whole disk partition table would be corrupted. As it was said, make a backup prior, but the conversion operation it self is designed so, that NO ORIGINAL DATA is touched. Btrfs makes snapshot of original FS version and uses free blocks to make further ...


1

I suggest that you immediately make a mirror of the damaged drive to avoid losing any more information. Your hardware is most likely bad and I would not mess with it further unless you like frustration. You can try to recover the image after restoriing it to a new disk. But I'm betting unless the data is extremely important that will be a time ...


0

Try a tar to /dev/null of the directory instead of a defrag... that will definitely not modify the disk, but will get all of the inodes cached. With large directories containing lots of files, ext4 indexes them in a hash tree so readdir() returns them in essentially random order. Trying to stat() them in that same order causes a lot of seeks, making it ...


1

An orphaned inode is one that has been unlinked but is still open in another process. For example running tail -f {file} in one shell followed by rm {file} in another. The filesystem keeps track of these so they can be cleaned up when the process quits. See this note on Ext4 Disk Layout.


0

4096B is only the initial size of the directory, equal to one sector. If however the amount of data to be stored (metadata, which includes file names) grows, so will the size of the directory, without it ever going down again to reduce problems with disk fragmentation: $ mkdir testdir $ cd testdir $ ls -lhd . drwxrwxr-x 2 me me 4.0K Jan 5 18:06 . $ ...


0

Take a look at the e2fsprogs package. It seems that you can get all your backup superblocks from dumpe2fs /dev/sd<partition-id> | grep -i superblock and then have e2fsck check the FS for you, or just try to do mount -o sb=<output-of-dumpe2fs> /dev/sd<partition-id> /your/mountpoint with a backup superblock. See this for reference: ...


2

All right, so for the first question it turns out the debugfs stats command tells what the starting blocks for every section of a group are. In addition, I guessed that inumbers had to be consecutive and increasing, so basic addition of the offset into the inode table and the imap command gave me the first inumbers; it also confirmed my suspicion about the ...


0

Yes that is about right. A couple of minor points to note are: As far as I can see the overhead of the filsystem itself isn't considered when calculating the number of inodes from this ratio, so the actual average size that a file can be will be slightly lower than 16834 when you consider the overhead superblock, inode table etc. Each inode itself is 256 ...



Top 50 recent answers are included