similar to: tune2fs: Filesystem has unsupported feature(s) while trying to open

tune2fs against a LVM (albeit formatted with ext4) is not the same as tune2fs against ext4. Could this possibly be a machine where uptime has outlived its usefulness? On Thu, Apr 21, 2016 at 10:02 PM, Chris Murphy <lists at colorremedies.com> wrote: > On Tue, Apr 19, 2016 at 10:51 AM, Matt Garman <matthew.garman at gmail.com> > wrote: > > > ># rpm -qf `which

On Sat, April 30, 2016 8:54 am, William Warren wrote: > uptime=insecurity. This sounds like MS Windows admin's statement. Are there any Unix admins still left around who remember systems with kernel that doesn't need [security] patching for few years? And libc that does not need security patches often. I almost said glibc, but on those Unixes it was libc; glibc, however, wasn't

uptime=insecurity. Patches must be kept up these days or your uptime won't matter when your server gets compromised. On 4/22/2016 4:33 AM, Rob Townley wrote: > tune2fs against a LVM (albeit formatted with ext4) is not the same as > tune2fs against ext4. > > Could this possibly be a machine where uptime has outlived its usefulness? > > On Thu, Apr 21, 2016 at 10:02 PM,

On Tue, Apr 19, 2016 at 10:51 AM, Matt Garman <matthew.garman at gmail.com> wrote: ># rpm -qf `which tune2fs` >e2fsprogs-1.41.12-18.el6.x86_64 That's in the CentOS 6.4 repo, I don't see a newer one through 6.7 but I didn't do a thorough check, just with google site: filter. > # cat /etc/redhat-release > CentOS release 6.5 (Final) > # uname -a > Linux

ALL systems need patching so obsessing about uptime is insecurity on its face. It doe not matter if it is windows or linux or anything else. On 4/30/2016 11:33 AM, Valeri Galtsev wrote: > On Sat, April 30, 2016 8:54 am, William Warren wrote: >> uptime=insecurity. > This sounds like MS Windows admin's statement. Are there any Unix admins > still left around who remember

On Sat, April 30, 2016 12:56 pm, William Warren wrote: > ALL systems need patching so obsessing about uptime is insecurity on its > face. It doe not matter if it is windows or linux or anything else. > As I said, I feel I hear MS Widows admins on this list. There are only two things that require reboot in UNIX and Linux Worlds. Kernel patches or rather installation of patched kernel

Hi, I have exactly the same problem that you experienced in Nov, 2013. I am using ext4 with journaled quota and the quota usage is only updating when I run quotacheck manually. Have you found a solution? Regards, Alex > I have set up user quotas on an ext4 filesystem. It does not appear that > the quota system is being updated, except when I manually run quotacheck. > > More detail:

I have set up user quotas on an ext4 filesystem. It does not appear that the quota system is being updated, except when I manually run quotacheck. More detail: I run "warnquota -s" from a script in /etc/cron.daily. I noticed that no one had received an "over quota" message in a long time. Using "repquota -as", it indeed looked as though everyone was under their

Not in my testing especially about the time of 6.4. On Apr 22, 2016 5:16 PM, "Gordon Messmer" <gordon.messmer at gmail.com> wrote: > On 04/22/2016 01:33 AM, Rob Townley wrote: > >> tune2fs against a LVM (albeit formatted with ext4) is not the same as >> tune2fs against ext4. >> > > tune2fs operates on the content of a block device. A logical volume

Just now I ran tune2fs -j on the root filesystem of a box running 2.6.0-test8. Then I edited /etc/fstab and changed the FS type to from ext2 to ext3, saved the file, and invoked vim on the file again. A few moments after this, the box hung. Unfortunately X was running at the time, and so I don't have any messages to cite. Is this a known problem?

On 9/16/13 9:44 AM, Nicolas Michel wrote: > Thanks for you help. I also tried adding some other informations as you suggest: > I can also take into account: > - "Reserved block count: XXXXXXX" from tune2fs that gives me the > number of blocks reserved for root > - Reserved GDT blocks: XXX > > But I didn't thought about the FS journal. How can I gather

Thanks for you help. I also tried adding some other informations as you suggest: I can also take into account: - "Reserved block count: XXXXXXX" from tune2fs that gives me the number of blocks reserved for root - Reserved GDT blocks: XXX But I didn't thought about the FS journal. How can I gather information about it? (it's size and any other information?) 2013/9/16

OK. Thanks for the journal information. I thought tune2fs -l and dumpe2fs were the same. In reality it's almost the same but not entirely ^^ I hear you about all the internal mecanisms that make the FS working or give it some features, and I do understand that it takes some place on the disk. However what I don't understand is why the number given in the "available column" is

I decided to start using ext3. My kernel 2.4.15p9. I downloaded and build util-linux-2.11m and e2fsprogs 1.25. I compiled ext3 in the kernel. I started converting my filesystems and thing went ok for the first few. I then started getting the following on each additional filesystem. [root@joker /root]# tune2fs -j /dev/hdc4 tune2fs 1.25 (20-Sep-2001) Creating journal inode: done This filesystem

I have been playing with external journals some more and thought I should share some experiences. I am running 2.4.16 with the ext3 patches from Andrew Morton and e2fsprogs 1.25 I have an ext3fs filesystem on an 8 drive RAID5 array and place the journal on a partition of the mirrored pair that I boot off (all drives SCSI). I have tried pulling the power cable and seeing what happens. I finally

Dear Mailinglist, this morning I had a very strange problem with my SuSE Groupware-Server SLOX 4.1. The webmail-access was very slow and even with thunderbird the access to my mailboxes was not okay. I rebooted the whole system, but the problem still was there. I thought, this may be a problem with cyrusd, but I realized, that the error was somewhere deeper in the system, maybe in the

I can't seem to find the answer to this question via web search... I changed some hardware on a server, and upon powering it back on, got the "/dev/xxx has gone 40 days without being check, check forced" message. Now it's running fsck on a huge (2 TB) ext3 filesystem (5400 RPM drives no less). How can I stop this in-progress check? Ctrl-C doesn't seem to have any effect.

Hello On root Partition is .journal visible . On all other Partitions is invisible. At which way I can move it manually to a hiden inode? I have delete with chattr -i /.journal rm -f /.journal and installed ext3 with tune2fs -j /dev/hdb1 And /.journal is again visible! -- MfG / With best Regards Rusmir Duško Registered Linux user: #130654 http://counter.li.org

On 04/22/2016 01:33 AM, Rob Townley wrote: > tune2fs against a LVM (albeit formatted with ext4) is not the same as > tune2fs against ext4. tune2fs operates on the content of a block device. A logical volume containing an ext4 system is exactly the same as a partition containing an ext4 filesystem.

Hi, on all of my CentOS7 VMs on different hypervisors the config file e2fsck.conf contains the line broken_system_clock = 1 I found this because on all of them, the root partition was not checked triggered by interval setting with tune2fs. Do you see similiar /default/ settings on your machines? Is it an issue only on VMs? I have no CentOS7 host on bare metal to compare. Thanks and cheers,