Tag Info

Hot answers tagged

31

Another option is to use blkid: $ blkid /dev/sda1 /dev/sda1: UUID="625fa1fa-2785-4abc-a15a-bfcc498139d1" TYPE="ext2" This recognizes most filesystem types and stuff like encrypted partitions. You can also search for partitions with a given type: # blkid -t TYPE=ext2 /dev/sda1: UUID="625fa1fa-2785-4abc-a15a-bfcc498139d1" TYPE="ext2" /dev/sdb1: ...


26

You can use sudo parted -l [shredder12]$ sudo parted -l Model: ATA WDC WD1600BEVT-7 (scsi) Disk /dev/sda: 160GB Sector size (logical/physical): 512B/512B Partition Table: msdos Number Start End Size Type File system Flags 1 32.3kB 8587MB 8587MB primary ext3 boot 4 8587MB 40.0GB 31.4GB primary ext4 2 ...


25

How do I tell what sort of data (what data format) is in a file? → Use the file utility. Here, you want to know the format of data in a device file, so you need to pass the -s flag to tell file not just to say that it's a device file but look at the content. You'll see output like this: # file -s /dev/sd* /dev/sda1: Linux rev 1.0 ext4 filesystem data, ...


24

check with lsof if there are files held open, space will not be freed until they are closed sudo /usr/sbin/lsof | grep deleted will tell you which deleted files are still held open


20

No. It won't give consistent results on the read-only client, because of caching. It's definitely not designed for it. You could expect to see IO errors returned to applications. There's probably still some number of oversights in the code, that could cause a kernel crash or corrupt memory used by any process. But most importantly, ext4 replays the ...


15

The page you reference (http://intgat.tigress.co.uk/rmy/uml/index.html) states: The utility also works on ext3 or ext4 filesystems. So I'm not sure where you're getting that it doesn't work on ext4 filesystems. Note that the zerofree utility is different from the zerofree kernel patch that is mentioned on the same page (which indeed does not seem to have ...


14

No, it doesn't. The issue isn't with the type of disk (spinning/non-spinning), it's with committing disk buffers from RAM to disk. If the power goes out suddenly, some of these buffers may never get committed to disk, and having barriers enabled improves your chances of recovering the filesystem. There's also an additional issue with the disk's on-board ...


12

use lsof to find the deleted, but open, file still consuming space lsof | grep deleted | grep etilqs_1IlrBRwsveCCxId chrome 3446 user 128u REG 253,2 16400 2364626 /var/tmp/etilqs_1IlrBRwsveCCxId (deleted) find the entry in /proc//fd/ that cooresponds to the filehandle ls -l ...


12

The man page of tune2fs gives you an explanation: Reserving some number of filesystem blocks for use by privileged processes is done to avoid filesystem fragmentation, and to allow system daemons, such as syslogd(8), to continue to function correctly after non-privileged processes are prevented from writing to the filesystem. It also acts as a ...


12

From the mke2fs man page: Be warned that it is not possible to expand the number of inodes on a filesystem after it is created, so be careful deciding the correct value for this parameter. So the answer is no. What you could do is shrink the existing ext4 volume (this requires unmounting the filesystem), use the free space to create a new ext4 volume ...


12

The field gets populated (see below) only coreutils stat does not display it. Apparently they're waiting for the xstat() interface. coreutils patches - aug. 2012 - TODO stat(1) and ls(1) support for birth time. Dependent on xstat() being provided by the kernel You can get the creation time through debugfs + stat: debugfs -R 'stat /etc/profile' ...


11

Yes, you can. This is explained very nicely in the ext4-wiki at kernel.org. Basically it all boils down to tune2fs -O extents,uninit_bg,dir_index /dev/DEV e2fsck -fDC0 /dev/DEV with /dev/DEV replaced by the partition in question. Although this should be non-destructive, I'd still strongly suggest to back up your data before doing it.


11

Theres no missing space. 5% reserved is rounded down to the nearest significant figure. 1k Blocks: 1922860848 Reserved 1k Blocks: (24418931 * 4) = 97675724 Total blocks used: 927384456 + 897800668 + 97675724 = 1922860848 Edit: Regarding your comment on the difference between df blocks and 'Block Count' blocks. So the 4k block difference is (1953514496 - ...


11

I assume you're hoping to find an equivalent of the uid=N and gid=N options supported by some of the other filesystems Linux's mount command knows about. Sorry, but no, ext4 doesn't have that option. These other filesystems have such an option in order to give permissions to files for a filesystem that may not have useful POSIX permissions. You're looking ...


11

The -T largefile flag adjusts the amount of inodes that are allocated at the creation of the file system. Once allocated, their number cannot be adjusted (at least for ext2/3, not fully sure about ext4). The default is one inode for every 16K of disk space. -T largefile makes it one inode for every megabyte. Each file requires one inode. If you don't have ...


10

Let's see. The device size is 1,465,138,583½ kB = 1,500,301,909,504 B. The filesystem consists of 366,284,288 blocks of 4096 B each, which is 1,500,300,443,648 B. I don't know what the remaining 1,465,856 B (1.4 MB) are used for (additional copies of the superblock? I know there are a few kB of space at the beginning for the bootloader.). The filesystem ...


10

The answer to your question lies in the e2fsck/problems.c file of the e2fsprogs source code. Looking for the PR_PREEN_OK flag should get you started. As the complete error handling is a bit more involved, due to the multitude of different error conditions that may occur, you are advised to have a closer look at the code if you are concerned about a specific ...


10

"Better" is subjective and not very meaningful. Nevertheless, you can get a good comparison of filesystems (including NTFS and ext4) on Wikipedia. There's also an article on PC World that covers it more briefly. Ultimately you should remember that performance metrics in this case are not really a good measure of filesystem performance, there are too many ...


10

Still another way, since you know you're running some flavor of ext?, is to look at the filesystem's feature list: # tune2fs -l /dev/sda1 | grep features If in the list you see: extent — it's ext4 no extent, but has_journal — it's ext3 neither extent nor has_journal — it's ext2 The parted and blkid answers are better if you want ...


9

Modern filesystems, particularly those designed to be efficient in multi-user and/or multi-tasking use cases, do a good fairly job of not fragmenting data until filesystems become near to full (there is no exact figure for where the "near to full" mark is as it depends on how large the filesystem is, the distribution of file sizes and what your access ...


9

kernel BUG at fs/ext4/inode.c:2118! invalid opcode: 0000 [#1] SMP Appears to be an issue with the ext4 driver in your kernel. Process mythbackend (pid: 27841, threadinfo ffff88004262a000, task ffff88007fb83330) mythbackend is triggering it. [<ffffffff811731df>] mpage_da_map_and_submit+0x2c6/0x2dc [<ffffffff8117390a>] ...


9

These days ext4 is considered the stable standard, and you should use it. Also all filesystems use delayed writing, ext4 just delays allocating where the blocks go until they are actually written, which helps reduce fragmentation. It also uses extents to track the blocks, which makes it more efficient.


9

The dot file, like every directory, contains a list of names for the files in this directory and their inode numbers. So if you once had lots of files in that directory (not unlikely for a "tmp" directory) that would have made the directory entry grow to this size. After the files are gone, the file system doesn't automatically shrink the directory file ...


8

Woohoo, I solved it :) The short answer is you can't mount >4k block size devices on x86 linux machines as far as I can tell without some serious kernel hacking. However, there is a work around.. using fuse-ext2 to mount the disk: fuseext2 -o ro -o sync_read /dev/sdb4 /mnt/ (you'll probably need to apt-get fuseext2 first..) works perfectly first time! ...


7

You can use a tool like PhotoRec to read the blocks and try to recover files. It actually recovers a lot of file types, not just images like the name may suggest. http://www.cgsecurity.org/wiki/PhotoRec


7

That's one of the most advertised benefits of ext4 (see it mentioned in the Features on Wikipedia). The reason? Filesystem developers worked hard to achieve this. Here's a short summary quoted from Wikipedia: Faster file system checking In ext4, unallocated block groups and sections of the inode table are marked as such. This enables e2fsck to ...


7

reduce reserved space to 4% # tune2fs -m4 /dev/sda4 df -h now showed 45M free. Saved my files quickly Put it back to 5% # tune2fs -m5 /dev/sda4


7

You should not use df because it shows the size as reported by the filesystem (in this case, ext4). Use the dumpe2fs -h /dev/mapper/ExistingExt4 command to find out the real size of the partition. The -h option makes dumpe2fs show super block info without a lot other unnecessary details. From the output, you need the block count and block size. ... ...


7

Unless you are talking about a solid-state drive, a high number of disk writes are not going to be the dominant factor in drive longevity. If you really want to avoid disk writes at all, look into tmpfs,


7

I have the same tool installed on Fedora 19, and I noticed in the .spec file a URL which lead to this page titled: Keeping filesystem images sparse. This page included some examples for creating test data so I ran the commands to create the corresponding files. Example $ dd if=/dev/zero of=fs.image bs=1024 seek=2000000 count=0 $ /sbin/mke2fs fs.image $ ls ...



Only top voted, non community-wiki answers of a minimum length are eligible