Tag Info

New answers tagged

3

There used to be an option to check ext2 filesystems at mount time, but that is no longer supported. Nowadays boot scripts check filesystems before mounting them, and your scripts should do so too. Mounting a filesystem does still check things to make sure it's safe to mount the filesystem; but it won't fix anything (beyond replaying the journal on ext3 or ...


0

CentOS 7 ( Currently using in VMware for testing ) since its rock solid & very stable found after googling alot. CentOS/RHEL is more for servers. You can get CentOS/RHEL to work as a desktop but it's probably easier to use something like Fedora which is geared more for desktop users. Fedora is more unstable but if you start out with something that's ...


9

I can't truly answer but I think this might help: Notice how each fragment is, at most, 32768 blocks in size (a power of 2, that should raise a flag that something is going on, and also give you a hint for something to look for). Also worth noting, those physical offsets between extents are pretty close to each other. From: Ext4 Disk Layout An ext4 ...


14

3 or 4 fragments in a 900mb file is very good. Fragmentation becomes a problem when a file of that size has more like 100+ fragments. It isn't uncommon for fat or ntfs to fragment such a file into several hundred pieces. You generally won't see better than that at least on older ext4 filesystems because the maximum size of a block group is 128 MB, and so ...


0

I have been gathering info about the journaling systems in ext3 and ext4, and a chapter in wikipedia on ext4 Delayed allocation and potential data loss, made me think of rsync as a potential cause for fragmentation. Googling that fraze sent me here, and I actually see described the result of the process I was going to ask about! The suggestion to tar to ...


2

By default, ext2/ext3/ext4 filesystems have 5% of the space reserved for the root user. This makes sense for the root filesystem in a typical configuration: it means that the system won't grind to a halt if a user fills up the disk, critical functionality will still work and in particular logs can still be written. It doesn't make sense in most other ...


2

Under most typical use cases, most filesystems created with default settings will have way more inodes than they will ever need. But that's actually a pretty good tradeoff considering: The inode table doesn't really waste all that much space, all in all. It's almost never worth reducing the number of inodes just to squeeze the last few bytes of available ...


0

This would have been the "lazy initialization" feature of Ext4 which zeroes out the inode tables on the first mount after creating the file system. This allows the file system to be created faster, but runs a kernel thread called "ext4lazyinit" in the background. You can confirm if this is happening by running "ps aux | grep ext4lazyinit". The process may ...


0

In order to show you a directory, these file managers need to at least scan the list of file names in the directory and the file types and other metadata. These are the same calls that ls -l makes. In addition, some file managers may inspect the contents of the file to give you more precise information about what's in them, like the file utility. They may ...


1

It's actually scanning the list of files that's slow. Something like this should do: find /home >/dev/null & That is, it will pre-cache the files in /home. But it will keep your disk busy for a while, it will cache both interesting and uninteresting subdirectories, and some subdirectories might still be purged from cache before you actually need ...


0

Not enough information. You say "the partition was ... changed to NTFS" but you don't say how. If all that changed was the partition type flag in the partition table (whether DOS or GPT), then that flag can be changed back and all will be fine. You can use gparted, parted, or even fdisk to make that kind of change. If the partition type changed in some ...


0

As per RedHat documentation you can't reduce mounted filesystem. Check here for detailed document


1

no, with ntfs-3g you've got read- and write-support for NTFS formated partitions. just additionally avoid the following characters: \ : * ? " < > | You will maybe loose the permissions... if this is important for you (which I doubt), you have to create a tar-file first and then transfer it to the NTFS-drive. Anyway... if you are free to choose the file ...


1

This sort of safety should not be tried to implement from scratch on top of a file system. Instead I suggest to reorganize your system and use ZFS. With ZFS any consistency is handled on the file system level without the need for you to keep track of checksums or other means, and without need to explicitly veryfy file state on every access or with every tool ...


4

If one could that easily detect when sectors are about to go bad or do go bad, it would likely have been worked into the filesystem by now. Due to the nature of the error, it will often be silent. You need a filesystem that does checksumming. On GNU/Linux BTRFS may be a good bet since I looked online and apparently support was introduced in Debian 6. ...


3

You can install and configure the SMART monitoring tools. On Debian the package is called smartmontools. These won't prevent disk failure but they will help identify precursors to possible disk failure. There is no configuration in the package installation, so you need first to enable SMART monitoring in the file /etc/default/smartmontools: # uncomment to ...


2

Because you can't foresee when and where a disk is corrupted, the easiest way to prevent that your backup is overwritten by a corrupted copy is doing a rotating backup. So basically you can do daily backups to different locations. When you notice a disk fault and you have several backups to restore from, even if the last one is overwritten by a corrupted ...



Top 50 recent answers are included