Tag Info

New answers tagged

4

Using strace would seem to indicate that the file sizes are indeed calculated by querying the files within the directory. Example Say I fill a directory with 3 1MB files. $ mkdir adir $ fallocate -l 1M adir/afile1.txt $ fallocate -l 1M adir/afile2.txt $ fallocate -l 1M adir/afile3.txt Now when we trace the du -h command: $ strace -s 2000 -o du.log du ...


0

It's difficult to predict the exact size of a filesystem, because a filesystem contains more than the files themselves. See Why are there so many different ways to measure disk usage? for some subtleties regarding disk usage. In particular: Each file ends with an incomplete block. Running du takes this into account, but you need to omit the -B argument, ...


1

LUKS by default uses 2 MiB for its header, mainly due to data alignment reasons. You can check this with cryptsetup luksDump (Payload offset: in sectors). If you don't care about alignment, you can use the --align-payload=1 option. As for ext4, it's complicated. Its overhead depends on the filesystem size, inode size, journal size and such. If you don't ...


0

I had the problem this weekend: 1000000 text files of 5-20 kb. These text files are never changed, so the best solution for me was mksquashfs: Today disk I/O is much more expensive than uncompressing 1 MB extra. It is, however, not a general solution: If you need to change or add files this will not work (In which case I would recommend Btrfs).


0

"LUKS has a 1032 sectors (a sector being 512 bytes) overhead in which it store the LUKS header. Following the header, encrypted data just takes as much space as its decrypted counterpart, linearly" See: http://glandium.org/blog/?p=139


0

I asked a very similar question not so long ago - fstrim trims more than half of partition size even though partition mounted with discard. There is a more detailed explanation/discussion of what happens on this question, but basically the record of what has been trimmed with fstrim (and the underlying FITRIM ioctl) is kept in kernel memory and is not ...


0

Apparently it is not possible to recover the old ext4 filesystem. I am currently recovering some files with Photorec, with mixed success. A response from the developing of UFS Explorer is as follow: The reason is ext4 on time of format destroys completely all inodes and even file system journal so volume only contains file data; usually it is ...


1

My recommendation is UFS Explorer. If that fails, you'll need professional assistance. Standard recovery rules apply... Don't write to the affected volume and try to recover to another device. Also see: How to recover XFS file system with "superblock read failed"


0

mkfs.ext4 -T largefile ... and never mind about defrag... Use LVM, not a filesystem.


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

As said with another related answer, you can't trust dumpe2fs in a mounted partition. It's very likely that it's erroneous or outdated. Unmount the partition and try again.


6

If you want to grant global write permission on that directory, you have to do chmod a+w wp.localhost [1] This is because omitting the 'who is affected' letter (u, g, o or a) implies a, but won't set bits that are set in your current umask. So, for example, if your umask was 0022, the 'write' bit is set in the 'group' and 'other' positions, and chmod ...


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 ...


3

The “Blockcount” value is the i_blocks field of the struct ext2_inode. This is the value that is returned to the stat syscall in the st_blocks field. For historical reasons, the unit of that field is 512-byte blocks — this was the filesystem block size on early Unix filesystems, but now it's just an arbitrary unit. You can see the value being incremented and ...



Top 50 recent answers are included