similar to: sw-raid1+ ext3 - can't fsck on boot?

From: Warren Young Sent: April 21, 2015 14:13 > On Apr 21, 2015, at 9:50 AM, Hugh E Cruickshank wrote: > > > > From: Kay Diederichs Sent: April 21, 2015 03:43 > >> > >> instead of having 20 for all of them, set > >> the first filesystem to 17, the second to 19, the third to > 23, and the > >> fourth to 29. > > > > Thanks but

From: Les Mikesell Sent: April 21, 2015 09:19 > > Why do you care about running them at the same time when it doesn't > take longer to run them all in parallel? Except I think the root > filesystem normally runs first. So you might want to stagger it vs. > everything else. I am trying to avoid running them at the same time in an effort to avoid 70 minute boot times (which is

Hey! I have some RHEL6 hypervisors and the VMs are in raw qemu image files in a local raid array linux raid + lvm + ext3. When a kernel update is installed a reboot is necessary, usually it has been more than 180 days since the last reboot and the file system is fsck'd and this takes 2-3 hours. I am curious to know if there is any documentation that addresses the pro's and con's of

From: Kay Diederichs Sent: April 21, 2015 03:43 > On 04/21/2015 06:08 AM, Hugh E Cruickshank wrote: > > > > The second idea was to set each filesystem to a different random > > count value. This would run the risk of having two or more > > executions at the same time but it would probably not be very > > frequent. > > Using "tune2fs -c", set the

From: Gordon Messmer Sent: April 21, 2015 10:30 > > On 04/21/2015 09:40 AM, Hugh E Cruickshank wrote: > > I accept that fscks are required on a periodic basis and I > am willing > > to reboot more often to achieve these but I would like to minimize > > downtime (during the reboot) where possible. > > Why do you accept that? Every article I have read on the

I know there is no straightforward way to recover deleted files on an ext3 file system, but is there any way to recover from an accidental mke2fs? -- --------------------------------------------------------------- Paul Raines email: raines@nmr.mgh.harvard.edu MGH/MIT/HMS Athinoula A. Martinos Center for Biomedical Imaging 149 (2301) 13th Street tel:(617)-724-2369

On Apr 22, 2015, at 11:56 AM, Hugh E Cruickshank <hugh at forsoft.com> wrote: > > I have done some "what if" testing. Using which tool? My simulator, or something you cooked up yourself? If the latter, would you care to share? I?ve updated mine to break out the stats for 3+ volumes instead of just reporting all multi-volume fscks together:

CentOS 6 Hi All: Over the weekend I had to reboot one of my systems and got hit with fsck runs on all of the filesystems. I would not mind so much except doing them all at once took over an hour. I would like to be able to stagger these, ideally only execute one fsck per reboot. I have been able to think of two possible solutions but neither is terrific. My first idea was to manually run fsck

drbd-0.7.19 under kernel 2.6.17-rc4 is running on a primary node standalone. There are 8 resources in the same group. fsck.ext3 -fv is being run simultaneously on all of them. Each of the drbd devices are running on an lv, which all belong to a single pv. The actual "disk" is a hardware RAID connected via SCSI (i.e., the mpt driver). Five of the fsck finished their tasks

drbd-0.7.19 under kernel 2.6.17-rc4 is running on a primary node standalone. There are 8 resources in the same group. fsck.ext3 -fv is being run simultaneously on all of them. Each of the drbd devices are running on an lv, which all belong to a single pv. The actual "disk" is a hardware RAID connected via SCSI (i.e., the mpt driver). Five of the fsck finished their tasks

drbd-0.7.19 under kernel 2.6.17-rc4 is running on a primary node standalone. There are 8 resources in the same group. fsck.ext3 -fv is being run simultaneously on all of them. Each of the drbd devices are running on an lv, which all belong to a single pv. The actual "disk" is a hardware RAID connected via SCSI (i.e., the mpt driver). Five of the fsck finished their tasks

On 04/21/2015 06:08 AM, Hugh E Cruickshank wrote: > CentOS 6 > > Hi All: > > Over the weekend I had to reboot one of my systems and got hit with > fsck runs on all of the filesystems. I would not mind so much except > doing them all at once took over an hour. I would like to be able to > stagger these, ideally only execute one fsck per reboot. I have been > able to

On Tue, Apr 21, 2015 at 11:40 AM, Hugh E Cruickshank <hugh at forsoft.com> wrote: > From: Les Mikesell Sent: April 21, 2015 09:19 >> >> Why do you care about running them at the same time when it doesn't >> take longer to run them all in parallel? Except I think the root >> filesystem normally runs first. So you might want to stagger it vs. >>

On 04/21/2015 09:40 AM, Hugh E Cruickshank wrote: > I accept that fscks are required on a periodic basis and I am willing > to reboot more often to achieve these but I would like to minimize > downtime (during the reboot) where possible. Why do you accept that? The default behavior for filesystems set up by Red Hat tools (anaconda) is not to fsck. Not by mount count, nor by time.

On Apr 21, 2015, at 9:50 AM, Hugh E Cruickshank <hugh at forsoft.com> wrote: > > From: Kay Diederichs Sent: April 21, 2015 03:43 >> >> instead of having 20 for all of them, set >> the first filesystem to 17, the second to 19, the third to 23, and the >> fourth to 29. > > Thanks but that is not much different then my second idea and does not > fully

Hello, I've just compiled 2.4.6 patched for ext3 filesystem and with out incident the conversion went fine. System Specs. Redhat 6.1 (highly hacked on since install on Sep 1999) kernel 2.4.6 gcc 2.95.2 egcs 2.91.66 XFree 4.1.0 I followed the docs, but I have once issue, on hardboot it still fscks the drives. Is this a cause of the rc scripts needing tweaking or a fstab setting. thanks

I recently ran into an issue where I couldn't create a file larger than 2GB on a particular ext3 filesystem. I was under the (mistaken) impression that >2GB support went in before ext3 support, and all ext3 filesystems would therefore support >2GB files on ia32. So, I started poking around and found that some of my ext3 filesystems have the "large_file" feature flag set on

Hi, I run several hundred servers that are used heavily (webhosting, etc.) all day long. Quite often we'll have a server that either needs a really long fsck (10 hours - 200 gig drive) or an fsck that evntually results in everything going to lost+found (pretty much a total loss). Would rebooting these servers monthly (or some other frequency) stop this? Is it correct to visualize this as

Hello, This may be a slightly rambling and inexpert question from point of view of the learned folks on this list - feel free to go and read something more interesting, but I am curious and a little alarmed about a recent event. I am running Linux from Scratch ("LFS"), under a locally compiled Kernel 2.4.20 (SMP). The root filsytem was created as ext2 and converted to ext3 with an

From: Mark Milhollan Sent: April 21, 2015 05:35 > On Mon, 20 Apr 2015, Hugh E Cruickshank wrote: > > >CentOS 6 > > >From ''man fstab'' ... > > The sixth field, (fs_passno), is used by the fsck(8) > program to determine the order > in which filesystem checks are done at reboot time. > The root filesystem should be >