Tag Info

Hot answers tagged

6

Don't get misled by the fact that only writeback mentions internal filesystem integrity. In ext3, whether you use journal, ordered or writeback, file system metadata is always journalled and that means internal file system integrity. The data modes offer a way of control over how ordinary data is written to the file system. So, if data integrity is your main ...


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


5

First I would double check that the disk is structured as you think it is from a partitions perspective. Typically the command: $ fdisk -l /dev/sdb For example: $ sudo fdisk -l /dev/sda Disk /dev/sda: 500.1 GB, 500107862016 bytes 255 heads, 63 sectors/track, 60801 cylinders, total 976773168 sectors Units = sectors of 1 * 512 = 512 bytes Sector size ...


4

From the mount manpage, -r, --read-only Mount the filesystem read-only. A synonym is -o ro. Note that, depending on the filesystem type, state and kernel behavior, the system may still write to the device. For example, Ext3 or ext4 will replay its journal if the filesystem is dirty. To prevent this ...


4

Both ext3 and ext4 are journaling filesystems, in addition this list several differences, the most relevant are: Maximum individual file size can be from 16 GB to 16 TB Overall maximum ext4 file system size is 1 EB (exabyte). 1 EB = 1024 PB (petabyte). 1 PB = 1024 TB (terabyte). Directory can contain a maximum of 64,000 subdirectories (as opposed to 32,000 ...


3

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


3

The id in the partition table doesn't have to have anything to do with what's actually in the partition. For example, there's no type for an XFS filesystem -- people just use "linux" (83). fdisk will say HPFS/NTFS until you change the partition type: fdisk /dev/sdb t 1 83 w And then reboot, or reattach the drive. (make sure it's not mounted first)


3

Won't work nowadays. Modern disks "hide" bad blocks (even the most carefully manufactured new disks have them, they are unavoidable with current data densites) by remapping them to spares. You'll "see" bad blocks only when the disk runs out of spares, and in my experience that means that 99% of the time the disk has hours (at best) left before joining the ...


3

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


3

I'm not sure how you can examine any particular superblock, but you can use this command to examine the general contents that all the superblocks share like so, using dumpe2fs. $ sudo dumpe2fs /dev/mapper/fedora_greeneggs-home | less Example $ sudo dumpe2fs /dev/mapper/fedora_greeneggs-home | less Filesystem volume name: <none> Last mounted on: ...


3

Beyond the wear and tear on the HDDs I can't see any reason why this would be dangerous. I've never come across a EXT3/EXT4 parameter that limits the amount of times you can do this. There isn't any counter I've seen either. In looking through the output from tune2fs I see nothing that I would find alarming which would lead me to believe that performing ...


3

EXT4 is good in the new versions of different distros. Don't use ext4 if you are still using older versions. Older version has some issues that have been fixed in new versions. resize unmounted volumes only to be safe. I used a "live cd" for conversion. went smoothly. I would recommend backups just to safe but they are just there as a pre-caution.


2

If you created an ext2 file-system on the entire disk, then sudo mount /dev/sdb /media/mynewdrive -t ext2 should be correct, but if you created an ext2 file-system on a partition then the command should be like: sudo mount /dev/sdb1 /media/mynewdrive -t ext2 (or s/sdb1/sdbN/ for the Nth partition). The fsck utility also applies to file-systems (which ...


2

As you have already noticed, main point is that you cannot prevent your filesystem from all kind of crash. What you can do: On software side, you can use fdatawrites after each important operation (See this 2003 post from Theodore T'so, a main Linux FS Kernel developer. it's still true. There's also this one about a major data loss hidden in older ...


2

Try changing which part of the man page you empahsize: writeback Data ordering is not preserved - data may be written into the main filesystem after its metadata has been committed to the journal. This is rumoured to be the highest-throughput option. It guarantees internal filesystem integrity, however it can allow old data to appear in ...


2

Looking here - https://launchpad.net/~develop7/+archive/ppa/+build/1545234 - looks like anyfs-tools failed to build for them as well. The manual is a recommended read (http://anyfs-tools.sourceforge.net/), especially this snippet: "anyfs-tools anyfs-tools allows a user to convert filesystems. There is only one requirement for the existing source filesystem: ...


2

THIS ENDED UP BEING A HARDWARE ISSUE Switching to the new shielded cables did not help, but replacing the old card with this one: http://www.amazon.com/gp/product/B000NTM9SY did get rid of the error messages and the strange behavior. Will post something new if anything changes. IMPORTANT NOTE FOR SATA ENCLOSURES: Even after doing the above, any drive ...


2

You don't need to switch to ext2, you can tune ext3. You can change fsck requirements of a filesystem using tune2fs. A quick look tells me the correct command is tune2fs -c <mount-count>, but see the man page for the details. You can change how data will be written to the ext3 filesystem during mounting. You want either data=journal or data=ordered. ...


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


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


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


1

You should always try and see if the man page (man mke2fs) is more informative than the help: -i bytes-per-inode Specify the bytes/inode ratio. mke2fs creates an inode for every bytes-per-inode bytes of space on the disk. The larger the bytes-per-inode ratio, the fewer inodes will be created. This value ...


1

You can purge the journal by either un-mounting, or remounting read-only (arguably a good idea when cloning). With ext4 you can also turn off the journal altogether (tune2fs -O ^has_journal), the .journal magic immutable file will be removed automatically. The journal data will still be on the underlying disk of course, so removing the journal and then ...



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