Tag Info

New answers tagged

1

The ext4 filesystem has no built-in snapshot feature. The generic way to make snapshots under Linux is at the level of the storage volume. Your filesystem must be on an LVM logical volume, which is Linux's own partition system, as opposed to directly on a platform-native disk partition. To create a snapshot of a logical volume, run lvcreate --snapshot. You ...


1

This should work: tune2fs -i180d <block device> The default unit is days, so 180 will be interpreted the same as 180d but explicit is better than implicit. For example: tune2fs -i180d /dev/sda3 Make sure you always use tune2fs when the filesystem is unmounted!


1

It does show the timestamp (with nanoseconds precision) but in hex; it's the field after crtime:, e.g. in your output 0x55b65ebc:970fe7cc. The part after the colon is the nanoseconds. This article gives more details and explains how to calculate the timestamp/nanoseconds. So, e.g. to convert the hex values to a timestamp a la stat you could run: date -d ...


2

It looks like debugfs does not yet support printing out the sub-second portion (the upper 30 bits of i_xtime_extra) of timestamps in its asctime-based format. From http://git.kernel.org/cgit/fs/ext2/e2fsprogs.git/tree/debugfs/debugfs.c : if (is_large_inode && large_inode->i_extra_isize >= 24) { fprintf(out, "%s ctime: 0x%08x:%08x -- ...


4

You may be in luck, and have backup superblocks on the partition. If you can remember the options used to create the filesystem (e.g. you just used defaults), then you can find the locations of the backups like so: sudo /sbin/mkfs.ext4 -n <original_options> <device> The -n is critically important - it is a "dry-run" option that won't write ...


2

First of all, make sure the disk is read-only, so that no more writes happen to it while trying to recover the data. The ext4 superblock is hard to find, because the contents vary a lot, depending on the inode count, block count etc. However, there is a magic signature 0xEF53 (16 bits) that you can try to search for. If you can find the right place, then ...


1

Same problem after truncating a SD card image where the SD had a few blocks less than the original. Repartitioned the drive with fdisk (see above), but message "Size in superblock is different from the physical size of the partition" remained. Found the solution here: ...


1

I tried my googlefu and it seems really hard to get a straight answer :) and on top of that it also got me curios. I'm gonna post my findings because this might get higher in the google search results. The file contains information on the buddy group cache of that specific disk and it's useful for the fragmentation status of said disk. The fields which I ...


1

If you hadn't blown away the old ext4, there might have been some hope for fsck to do some repairs and find some intact directory structures. There might actually still be hope for that, by using an alternate superblock that was in the part of the disk you didn't mess up with mkfs. Or if your old FS had a different number of backup superblocks than your ...


-1

How Ext4 Extents Work? Earlier Ext2 and Ext3 had the limitation on the size of the file. It used 32 bit block number to access the data blocks. So that limited the maximum size of file to be 2^32 * blocksize(eg. 4k**) = 16TB*. Also the access time for large Files were slow because in had to go through lots of indirection.Ext4 Filesystem can support very ...


2

You can't fix LVM by growing size back to original size, unless you were very lucky and the LV had no fragmentation whatsoever due to previous resizes. Chances are the new LV will have the first 20G or so of your original filesystem but the remaining 780G (or whatever) are scrambled eggs (wrong data, wrong offset, wrong order). And that's assuming you're ...


2

The master boot record (MBR) at the beginning of a disk contains only 446 bytes of code, so it is tiny and cannot do much. Therefore, a common booting technique is to do what is called "chain loading," where the MBR loads code at the beginning of the active partition and jumps to that code. By leaving the first two sectors free, the EXT file system allows ...


2

Suggestions for better-than-ext4 choices for storing masses of small files: If you're using the filesystem an object store, you might want to look at using a filesystem that specializes in that, possibly to the detriment of other characteristics. Google found Ceph, which appears to be open source, and can be mounted as a POSIX filesystem, but also accessed ...


6

Bug in the implementation of ext4 feature dir_index which you are using on your destination filesystem. Solution : recreate filesytem without dir_index. Or disable feature using tune2fs (some caution required, see related link Novell SuSE 10/11: Disable H-Tree Indexing on an ext3 Filesystem which although relates to ext3 may need similar caution. (get a ...


0

While I have never used beets, I can give you some general info. First you are correct, in one regard at least. Generally speaking 300 Gigs of data is 300 Gigs of data. The file system should not matter too much. There are a few things you can check to make sure things are going smoothly. First is free inodes. When you run df -h you should get free space ...



Top 50 recent answers are included