Hot answers tagged ext3
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. Sometimes you'll need the -L flag as well, if the device file name is a symbolic link. You'll see ...
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
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: ...
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 ...
I guess you got that one letter into the file with echo a > file or vim file, which means, you'll have that letter and an additional newline in it (two characters, thus two bytes). ls -l shows file size in bytes, not blocks (to be more specific: file length): $ echo a > testfile $ ls -l testfile -rw-r--r-- 1 user user 2 Apr 28 22:08 testfile $ cat -A ...
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 ...
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 ...
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 ...
I think you're confused, possibly because you've read several documents that use different terminology. Terms like “block size” and “cluster size” don't have a universal meaning, even within the context of filesystem literature. Filesystems For ext2 or ext3, the situation is relatively simple: each file occupies a certain number of blocks. All blocks on a ...
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 ...
On an ext4 filesystem (like ext2, ext3, and most other unix-originating filesystems), the effective file permissions don't depend on who mounted the filesystem or on mount options, only on the metadata stored within the filesystem. If you have a removable filesystem that uses different user IDs from your system, you can use bindfs to provide a view of any ...
First, you're right to suspect that “all data” doesn't mean the whole file. In fact, that layer of the filesystem operates on fixed-size file blocks, not on whole files. At that level, it's important to keep a bounded amount of data, so working on whole files (which can be arbitrary large) wouldn't work. Second, there's a misconception in your question. The ...
No. ext3fs doesn't support block fragmentation so a one byte file will use a whole 4096 block. On the opposite, for example UFS supports four fragments in a block so small files won't fill a file system as fast as they will do on ext3fs. This is unrelated to disk fragmentation which is about file data blocks not being contiguous and sequential.
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.
Try a differfent program; maybe this will be more accurate: df -h
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 ...
You can't convert, but can reformat the partition. Boot into Ubuntu or from a live CD and format the partition from there. Be careful not to format the wrong partition. mkfs.ext3 /dev/hdx1
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
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 ...
To add to the other answers: Traditional Unix permissions are broken down into: read (r) write (w) execute file/access directory (x) Each of those is stored as a bit, where 1 means permitted and 0 means not permitted. For example, read only access, typically written r--, is stored as binary 100, or octal 4. There are 3 sets of those permissions, which ...
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
First, run a filesystem check, e2fsck -f ./system.img. Without this, it may proceed to enlarge the raw file, but fail to make any meaningful changes to the filesystem. To reduce the size of the file system: resize2fs ./system.img 50M To enlarge: resize2fs ./system.img 300M resize2fs automatically adjusts the file size for you.
You run e2fsck -D on the unmounted filesystem.
The purpose of reserving a small number of blocks for root's use only is to give root a chance to log in and give them a little bit of breathing room to make space in case the disk becomes completely full. Without it, root could be prevented from logging in because the login process fails when it gets unexpected errors writing files (like utmp and wtmp, ...
try using df -T see man df for more options still one more way I found is cfdisk
When setting up a disk or partition there are 2 aspects to doing this. The first is the act of laying down a partition table scheme on the disk using typically either MBR (Master Boot Record) or GPT (GUID Partitioning Table) formats. Both of these lay down a "structure" on the disk. MBR If you take a look at the structure of an MBR you'll notice that ...
I think that the deep answer is the following: Logical file length and disk space occupied are really different things. As the other answers show, in principle a file created with two bytes has length two bytes (show by ls -l) and occupy 4 KiB ( show by duor ls -ls). See: 1& [:~/tmp] % echo -n A > test 1& [:~/tmp] % ls -l test ...
If you want to ensure fragmentation but not prevent it (so you only have partial control over what happens), and you don't care about the specifics of the fragmentation, here's a quick & dirty way of doing things. To create a file of n blocks in at least two fragments: Open the file with synchronous writes, write m < n blocks. Open another file. ...
Because, if you mount the ext3 in writable mode, there are a few things that get updated, like the last mount date. Try if this also happens when you mount with -o ro.
Only top voted, non community-wiki answers of a minimum length are eligible