RFE: autofsck

[Ahmed Kamal]

I would like to propose

echo AUTOFSCK_DEF_CHECK=yes >> /etc/sysconfig/autofsck
echo 'AUTOFSCK_OPT="-y"' >> /etc/sysconfig/autofsck

Working with a local ISP in some rural area where there's a lot of power
cuts! The ISP guys were asking like, "Why is it that Linux boxes need manual
intervention to get back up after a power cut!" .. "Can't you script what
you're doing to get it back up" ?!
Does not having this as the default makes sense in some tangible number of
cases ?!

[Eric Sandeen]

Ahmed Kamal wrote:
>  I would like to propose
>  
>  echo AUTOFSCK_DEF_CHECK=yes >> /etc/sysconfig/autofsck
>  echo 'AUTOFSCK_OPT="-y"' >> /etc/sysconfig/autofsck
>  
>  Working with a local ISP in some rural area where there's a lot of power
>  cuts! The ISP guys were asking like, "Why is it that Linux boxes need
>  manual intervention to get back up after a power cut!" .. "Can't you
>  script what you're doing to get it back up" ?!
>  Does not having this as the default makes sense in some tangible number
>  of cases ?!
>   
Adding -y could potentially be dangerous.  e2fsck asks when the answer
isn't obvious.  In some situations, perhaps, but I probably would not
make this default.

I'm more concerned that you're seeing so many problems; with a
journaling filesystem you really shouldn't have any filesystem metadata
integrity problems on power loss; that is, if you have barriers on
(which ext3 doesn't by default) and if your storage can pass barriers
(which lvm doesn't), or if you have drive write cache disabled (which
hurts performance pretty badly).

I'd rather address the root of the problem and sort out why, if you are
paying the journaling overhead penalty at runtime, it's not saving you
on power loss.

-Eric

LVM negates benefits of jounaling filesystems? [was RFE: autofsck]

[Chuck Anderson]

On Tue, Jun 10, 2008 at 08:36:31AM -0500, Eric Sandeen wrote:
>  journaling filesystem you really shouldn't have any filesystem
> metadata
>  integrity problems on power loss; that is, if you have barriers on
>  (which ext3 doesn't by default) and if your storage can pass barriers
>  (which lvm doesn't), or if you have drive write cache disabled (which
>  hurts performance pretty badly). 
I wasn't aware that LVM destroyed the kind of guarantees about 
filesystem metadata being written out to disk that jounaling 
filesystems rely on?  If so, should we perhaps rethink the decision to 
use LVM by default on Fedora installs?

LVM negates benefits of jounaling filesystems? [was RFE: autofsck]

[Eric Sandeen]

Chuck Anderson wrote:
>  On Tue, Jun 10, 2008 at 08:36:31AM -0500, Eric Sandeen wrote:
> > journaling filesystem you really shouldn't have any filesystem metadata
> > integrity problems on power loss; that is, if you have barriers on
> > (which ext3 doesn't by default) and if your storage can pass barriers
> > (which lvm doesn't), or if you have drive write cache disabled (which
> > hurts performance pretty badly).
>  
>  I wasn't aware that LVM destroyed the kind of guarantees about 
>  filesystem metadata being written out to disk that jounaling 
>  filesystems rely on?  If so, should we perhaps rethink the decision to 
>  use LVM by default on Fedora installs? 
I wouldn't say destroys, but at least reduces.  See
http://lwn.net/Articles/283161/ and associated lkml thread...

By default, lvm on fedora is almost always on a single device, and Andi
Kleen has sent a patch to allow barriers to pass on that setup:
http://lkml.org/lkml/2008/2/15/125 but AFAICT it's not been merged yet.

Barriers do have performance impact, which is probably historically why
they're off by default on ext3.  I'm not totally convinced that it's a
good  tradeoff.  xfs has them on by default; I'm not sure about
reiserfs.  My patch to enable them by default on ext4 just went upstream.

-Eric

LVM negates benefits of jounaling filesystems? [was RFE: autofsck]

[Alan Cox]

On Tue, Jun 10, 2008 at 09:05:34AM -0500, Eric Sandeen wrote:
>  Barriers do have performance impact, which is probably historically
> why
>  they're off by default on ext3.  I'm not totally convinced that it's a
The cost is dropping rapidly with SATA devices. With a modern SATA disk and
NCQ we really really want them on - you've got 31 commands in flight and 16MB
or so of drive cache that will be written back in *arbitary* order. Thats
a recipe for disaster. A few years ago with one command at a time wind up
disks and at most 2MB it wasn't so bad. It really should be getting set on by
either our kernel or the installer in the SATA cases.

Alan

LVM negates benefits of jounaling filesystems? [was RFE: autofsck]

[Eric Sandeen]

Alan Cox wrote:
>  On Tue, Jun 10, 2008 at 09:05:34AM -0500, Eric Sandeen wrote:
> > Barriers do have performance impact, which is probably historically why
> > they're off by default on ext3.  I'm not totally convinced that it's a
>  
>  The cost is dropping rapidly with SATA devices. With a modern SATA disk and
>  NCQ we really really want them on - you've got 31 commands in flight and 16MB
>  or so of drive cache that will be written back in *arbitary* order. Thats
>  a recipe for disaster. A few years ago with one command at a time wind up
>  disks and at most 2MB it wasn't so bad. It really should be getting set on by
>  either our kernel or the installer in the SATA cases.
>  
>  Alan
>   
I think the problem is, barriers are really implemented as drive cache
flushes.  So under certain workloads the performance really does hurt.
But if the alternative is a good chance of filesystem corruption on
power loss, remind me again why we run a journaling fileystem at all?  :)

If ext3 doesn't get barriers on by default upstream then I would suggest
that yes, we should patch the kernel ourselves to do so, or set the
installer to create fstabs which specify it for filesystems that don't
have barriers on by default.  ... after lvm stops filtering it out, anyway.

-Eric

LVM negates benefits of jounaling filesystems? [was RFE: autofsck]

[Callum Lerwick]

On Tue, Jun 10, 2008 at 9:53 AM, Eric Sandeen <sandeen(a)redhat.com&gt; wrote:

>  I think the problem is, barriers are really implemented as drive
> cache
>  flushes.  So under certain workloads the performance really does hurt.
>  But if the alternative is a good chance of filesystem corruption on
>  power loss, remind me again why we run a journaling fileystem at all?  :)
>
>  If ext3 doesn't get barriers on by default upstream then I would suggest
>  that yes, we should patch the kernel ourselves to do so, or set the
>  installer to create fstabs which specify it for filesystems that don't
>  have barriers on by default.  ... after lvm stops filtering it out, anyway. 

I would like to put in my +1 for this. Performance is pointless on if you
can not trust that your data is safe. I have on many occasions run fscks on
my supposedly clean ext3 filesystems, only to find some mild corruption. How
can this happen? Isn't journaling supposed to prevent this? One day I ran a
fsck before doing some filesystem resizing, only to find one of my
irreplacible personal photos had become corrupted. I had no way to know when
or why this file got corrupted, it had been written to disk some time ago
and never touched since. I trusted journaling, and it failed me. (Yes, I
have a backup. I think...) After this, I now turn on autofsck on all my
machines, so that corruption at least can't go undetected for years. Which
means after a power fail it takes my primary desktop with a pretty full
250gb drive 20-30 minutes to come back up, which is incredibly irritating,
but I have to know my data is safe. I've even picked up a habit of
obsessively checksumming all my really important files. I wish the
filesystem would help do this for me. (ZFS...)

Knowing is half the battle. See, what can happen here, is a file can get
corrupted, and I may not notice until years later. By then I may have cycled
through several full backups, and long since lost the backup I did have of
the file...

This must be fixed. Only through a long painful process of losing faith have
I learned to not trust my filesystems. I suspect there are many others out
there who have been bitten by filesystem corruption and just don't know it
yet.

Only now do I learn the likely reason for this corruption. How would I have
reported this? I just assumed it was hardware glitches.

LVM negates benefits of jounaling filesystems? [was RFE: autofsck]

[Eric Sandeen]

Callum Lerwick wrote:

>  I would like to put in my +1 for this. Performance is pointless on
> if
>  you can not trust that your data is safe. I have on many occasions run
>  fscks on my supposedly clean ext3 filesystems, only to find some mild
>  corruption. How can this happen? Isn't journaling supposed to prevent
>  this? One day I ran a fsck before doing some filesystem resizing, only
>  to find one of my irreplacible personal photos had become corrupted. I
>  had no way to know when or why this file got corrupted, it had been
>  written to disk some time ago and never touched since. I trusted
>  journaling, and it failed me.  
Filesystem corruption can happen for many reasons, and journaling cannot
save you from them all.  Think  about bad cables, memory, kernel bugs,
bad hardware, rogue writes to the block device, etc.  Journaling doesn't
help you in the face of any of these problems.  If you are talking about
data corruption, it could have been an application bug for example (did
a photo editor corrupt it when you wrote the edited version?)  There is
a long line of things which can go wrong, unfortunately.  Trusting
journalling to keep all your data safe now and forevermore is misguided.

>  (Yes, I have a backup. I think...) After
>  this, I now turn on autofsck on all my machines, so that corruption at
>  least can't go undetected for years. Which means after a power fail it
>  takes my primary desktop with a pretty full 250gb drive 20-30 minutes to
>  come back up, which is incredibly irritating, but I have to know my data
>  is safe. I've even picked up a habit of obsessively checksumming all my
>  really important files. I wish the filesystem would help do this for me.
>  (ZFS...)
>  
>  Knowing is half the battle. See, what can happen here, is a file can get
>  corrupted, and I may not notice until years later. By then I may have
>  cycled through several full backups, and long since lost the backup I
>  did have of the file...
>  
>  This must be fixed. Only through a long painful process of losing faith
>  have I learned to not trust my filesystems. I suspect there are many
>  others out there who have been bitten by filesystem corruption and just
>  don't know it yet.
>  
>  Only now do I learn the likely reason for this corruption. How would I
>  have reported this? I just assumed it was hardware glitches. 
True, corruption from out-of-order writes due to lack of barriers is
hard to identify as such.  But unfortunately there are a few other
things that could have gone wrong too.  There are things in the works to
help on the integrity front, though (see
http://oss.oracle.com/projects/data-integrity/ for example).

-Eric

LVM negates benefits of jounaling filesystems? [was RFE: autofsck]

[Ahmed Kamal]

Reference this: http://blogs.sun.com/bonwick/entry/casablanca
Does anyone know if we're getting ZFS anytime soon?!

On Wed, Jun 11, 2008 at 7:56 PM, Eric Sandeen <sandeen(a)redhat.com&gt; wrote:

>  Callum Lerwick wrote:
>
>  > I would like to put in my +1 for this. Performance is pointless on if
>  > you can not trust that your data is safe. I have on many occasions run
>  > fscks on my supposedly clean ext3 filesystems, only to find some mild
>  > corruption. How can this happen? Isn't journaling supposed to prevent
>  > this? One day I ran a fsck before doing some filesystem resizing, only
>  > to find one of my irreplacible personal photos had become corrupted. I
>  > had no way to know when or why this file got corrupted, it had been
>  > written to disk some time ago and never touched since. I trusted
>  > journaling, and it failed me.
>
>  Filesystem corruption can happen for many reasons, and journaling cannot
>  save you from them all.  Think  about bad cables, memory, kernel bugs,
>  bad hardware, rogue writes to the block device, etc.  Journaling doesn't
>  help you in the face of any of these problems.  If you are talking about
>  data corruption, it could have been an application bug for example (did
>  a photo editor corrupt it when you wrote the edited version?)  There is
>  a long line of things which can go wrong, unfortunately.  Trusting
>  journalling to keep all your data safe now and forevermore is misguided.
>
>  > (Yes, I have a backup. I think...) After
>  > this, I now turn on autofsck on all my machines, so that corruption at
>  > least can't go undetected for years. Which means after a power fail it
>  > takes my primary desktop with a pretty full 250gb drive 20-30 minutes to
>  > come back up, which is incredibly irritating, but I have to know my data
>  > is safe. I've even picked up a habit of obsessively checksumming all my
>  > really important files. I wish the filesystem would help do this for me.
>  > (ZFS...)
>  >
>  > Knowing is half the battle. See, what can happen here, is a file can get
>  > corrupted, and I may not notice until years later. By then I may have
>  > cycled through several full backups, and long since lost the backup I
>  > did have of the file...
>  >
>  > This must be fixed. Only through a long painful process of losing faith
>  > have I learned to not trust my filesystems. I suspect there are many
>  > others out there who have been bitten by filesystem corruption and just
>  > don't know it yet.
>  >
>  > Only now do I learn the likely reason for this corruption. How would I
>  > have reported this? I just assumed it was hardware glitches.
>
>  True, corruption from out-of-order writes due to lack of barriers is
>  hard to identify as such.  But unfortunately there are a few other
>  things that could have gone wrong too.  There are things in the works to
>  help on the integrity front, though (see
>  http://oss.oracle.com/projects/data-integrity/ for example).
>
>  -Eric
>
>  --
>  fedora-devel-list mailing list
>  fedora-devel-list(a)redhat.com
>  https://www.redhat.com/mailman/listinfo/fedora-devel-list
>

LVM negates benefits of jounaling filesystems? [was RFE: autofsck]

[Yaakov Nemoy]

2008/6/11 Callum Lerwick <seg(a)haxxed.com&gt;:
>  On Tue, Jun 10, 2008 at 9:53 AM, Eric Sandeen
> <sandeen(a)redhat.com&gt; wrote:
> >
> > I think the problem is, barriers are really implemented as drive cache
> > flushes.  So under certain workloads the performance really does hurt.
> > But if the alternative is a good chance of filesystem corruption on
> > power loss, remind me again why we run a journaling fileystem at all?  :)
> >
> > If ext3 doesn't get barriers on by default upstream then I would suggest
> > that yes, we should patch the kernel ourselves to do so, or set the
> > installer to create fstabs which specify it for filesystems that don't
> > have barriers on by default.  ... after lvm stops filtering it out,
> > anyway.
>
>  I would like to put in my +1 for this. Performance is pointless on if you
>  can not trust that your data is safe. I have on many occasions run fscks on
>  my supposedly clean ext3 filesystems, only to find some mild corruption. How
>  can this happen? Isn't journaling supposed to prevent this? One day I ran a
>  fsck before doing some filesystem resizing, only to find one of my
>  irreplacible personal photos had become corrupted. I had no way to know when
>  or why this file got corrupted, it had been written to disk some time ago
>  and never touched since. I trusted journaling, and it failed me. (Yes, I
>  have a backup. I think...) After this, I now turn on autofsck on all my
>  machines, so that corruption at least can't go undetected for years. Which
>  means after a power fail it takes my primary desktop with a pretty full
>  250gb drive 20-30 minutes to come back up, which is incredibly irritating,
>  but I have to know my data is safe. I've even picked up a habit of
>  obsessively checksumming all my really important files. I wish the
>  filesystem would help do this for me. (ZFS...)
>
>  Knowing is half the battle. See, what can happen here, is a file can get
>  corrupted, and I may not notice until years later. By then I may have cycled
>  through several full backups, and long since lost the backup I did have of
>  the file...
>
>  This must be fixed. Only through a long painful process of losing faith have
>  I learned to not trust my filesystems. I suspect there are many others out
>  there who have been bitten by filesystem corruption and just don't know it
>  yet.
>
>  Only now do I learn the likely reason for this corruption. How would I have
>  reported this? I just assumed it was hardware glitches. 
Journaling won't save you from this problem, necessarily.  What you
gain from journaling is when your process aborts half way through
because of any failure at all.  The integrity you get is not that
every piece of data is intact and correct, but that no bit is in a
transitory state.  This means any transaction, or change of state from
A to B, that affects more than one bit on the hard drive, is a
concrete, isolated and discrete change.  This is the only guarantee
you get from a journaled file system.

This means, your system crashes while doing a banking transaction, you
don't lose money without a record being made to whom you paid it to.
It means that while rotating a photo, your power goes out, you don't
have half a rotate photo saved on your hard drive.  It means that
there are no lost blocks on your hard drive of files that didn't save
while doing something very critical.  File copy operations are either
completed or not.

You don't gain long term storage.  You do gain transaction security.

-Yaakov

LVM negates benefits of jounaling filesystems? [was RFE: autofsck]

[Eric Sandeen]

Yaakov Nemoy wrote:

>  This means, your system crashes while doing a banking transaction,
> you
>  don't lose money without a record being made to whom you paid it to.
>  It means that while rotating a photo, your power goes out, you don't
>  have half a rotate photo saved on your hard drive. 
Well, not in general, at least not from normal filesystem journaling.
The stuff you're talking about here is by and large the responsibility
of the app doing the writing.  Filesystem journaling is often only for
metadata, to ensure metadata consistency, or something like
data=journaled... but if your photo app writes out half of the edited
jpeg over the top of the existing file in one syscall and then you crash
before it makes a 2nd intended write, in general journaling is not going
to help you there, either.

see for example this talk:

eat my data: how everybody gets file IO wrong
http://lca2007.linux.org.au/talk/278.html

We'll discuss:
- when data hits disk
- what causes data to hit disk
- how you can ensure that data is on disk
- how applications get this wrong
- how a file system is not a database (and vice versa)

-Eric

LVM negates benefits of jounaling filesystems? [was RFE: autofsck]

[Callum Lerwick]

On Wed, Jun 11, 2008 at 4:26 PM, Yaakov Nemoy <loupgaroublond(a)gmail.com&gt;
wrote:

>  Journaling won't save you from this problem, necessarily.  What
> you
>  gain from journaling is when your process aborts half way through
>  because of any failure at all.  The integrity you get is not that
>  every piece of data is intact and correct, but that no bit is in a
>  transitory state.  This means any transaction, or change of state from
>  A to B, that affects more than one bit on the hard drive, is a
>  concrete, isolated and discrete change.  This is the only guarantee
>  you get from a journaled file system. 

I again point out this is a file that was written once and never again
modified. Nothing should have been writing to it. The metadata got trashed
somehow, as I remember it gave some "inode has wrong size" error, I told
e2fsck to fix it and the file ended up 0 bytes. I don't see how this could
be blamed on anything but the kernel or hardware, and this particular
machine is fairly new, with decent quality hardware, so I'm pretty certain
the hardware isn't flaky.

Though now that I think of it I've had problems with the r300 drivers
locking up the system. Should a hardware lockup cause this kind of problem?
If you ask me, no, not to a file that's not even open. Especially as I
obsessively type "sync" before doing anything at all risky, but it seems I
can't necessarily even trust sync to do its job. Go figure.

LVM negates benefits of jounaling filesystems? [was RFE: autofsck]

[Alan Cox]

On Tue, Jun 10, 2008 at 09:46:33AM -0400, Chuck Anderson wrote:
>  filesystem metadata being written out to disk that jounaling 
>  filesystems rely on?  If so, should we perhaps rethink the decision to 
>  use LVM by default on Fedora installs? 
I would agree with that regardless (although LVM barrier handling if it is
broken does want fixing - I was under the impression it was ok). My boxes
are much faster without LVM so I always turn it off.

LVM negates benefits of jounaling filesystems? [was RFE: autofsck]

[Eric Sandeen]

Alan Cox wrote:
>  On Tue, Jun 10, 2008 at 09:46:33AM -0400, Chuck Anderson wrote:
> > filesystem metadata being written out to disk that jounaling 
> > filesystems rely on?  If so, should we perhaps rethink the decision to 
> > use LVM by default on Fedora installs?
>  
>  I would agree with that regardless (although LVM barrier handling if it is
>  broken does want fixing - I was under the impression it was ok). My boxes
>  are much faster without LVM so I always turn it off. 
LVM barriers aren't so much broken as simply un-implemented by design.

static int dm_request(struct request_queue *q, struct bio *bio)
{
...
        /*
         * There is no use in forwarding any barrier request since we can't
         * guarantee it is (or can be) handled by the targets correctly.
         */
        if (unlikely(bio_barrier(bio))) {
                bio_endio(bio, -EOPNOTSUPP);
                return 0;
        }

... and somebody should probably measure the lvm overhead in general, I
suppose.  :)

-Eric

LVM negates benefits of jounaling filesystems? [was RFE: autofsck]

[Alan Cox]

On Tue, Jun 10, 2008 at 09:49:16AM -0500, Eric Sandeen wrote:
>          if (unlikely(bio_barrier(bio))) {
>                  bio_endio(bio, -EOPNOTSUPP);
>                  return 0;
>          }
>  
>  ... and somebody should probably measure the lvm overhead in general, I
>  suppose.  :) 
About 30% for disk performance on my test box. Obviously that isn't all
some LVM code corner case and there are other problems in there to reach
that difference on dbench. That's FC8 and I believe some lvm fixes for
performance have occurred since I did the runs (FC8 no updates).

Alan

LVM negates benefits of jounaling filesystems? [was RFE: autofsck]

[Eric Sandeen]

Alan Cox wrote:
>  On Tue, Jun 10, 2008 at 09:49:16AM -0500, Eric Sandeen wrote:
> >         if (unlikely(bio_barrier(bio))) {
> >                 bio_endio(bio, -EOPNOTSUPP);
> >                 return 0;
> >         }
> >
> > ... and somebody should probably measure the lvm overhead in general, I
> > suppose.  :)
>  
>  About 30% for disk performance on my test box. Obviously that isn't all
>  some LVM code corner case and there are other problems in there to reach
>  that difference on dbench. That's FC8 and I believe some lvm fixes for
>  performance have occurred since I did the runs (FC8 no updates).
>  
>  Alan
>   
quick test; fast hardware raid on fibrechannel, 4 cpu opteron, 8G
memory, 4-threaded dbench for 600s, 120s warmup, 500G ext3 fs, 2.6.26-rc2.

ext3 on /dev/sdc:
Throughput 679.495 MB/sec 4 procs

ext3 on /dev/mapper/myvg-lvol0 on /dev/sdc:
Throughput 665.599 MB/sec 4 procs

-Eric

LVM negates benefits of jounaling filesystems? [was RFE: autofsck]

[Alan Cox]

On Tue, Jun 10, 2008 at 11:21:19AM -0500, Eric Sandeen wrote:
>  quick test; fast hardware raid on fibrechannel, 4 cpu opteron, 8G
>  memory, 4-threaded dbench for 600s, 120s warmup, 500G ext3 fs, 2.6.26-rc2.
>  
>  ext3 on /dev/sdc:
>  Throughput 679.495 MB/sec 4 procs
>  
>  ext3 on /dev/mapper/myvg-lvol0 on /dev/sdc:
>  Throughput 665.599 MB/sec 4 procs 
Nice numbers, although I was testing pair of ATA disks ;)

LVM negates benefits of jounaling filesystems? [was RFE: autofsck]

[Eric Sandeen]

Alan Cox wrote:
>  On Tue, Jun 10, 2008 at 11:21:19AM -0500, Eric Sandeen wrote:
> > quick test; fast hardware raid on fibrechannel, 4 cpu opteron, 8G
> > memory, 4-threaded dbench for 600s, 120s warmup, 500G ext3 fs, 2.6.26-rc2.
> >
> > ext3 on /dev/sdc:
> > Throughput 679.495 MB/sec 4 procs
> >
> > ext3 on /dev/mapper/myvg-lvol0 on /dev/sdc:
> > Throughput 665.599 MB/sec 4 procs
>  
>  Nice numbers, although I was testing pair of ATA disks ;)
>   
Should probably re-test that too.  :)

-Eric (wasn't *trying* to show off...)

LVM negates benefits of jounaling filesystems? [was RFE: autofsck]

[Bruno Wolff III]

On Tue, Jun 10, 2008 at 09:49:16 -0500,
  Eric Sandeen <sandeen(a)redhat.com&gt; wrote:
>  
>  LVM barriers aren't so much broken as simply un-implemented by design.
>  
>  static int dm_request(struct request_queue *q, struct bio *bio)
>  {
>  ...
>          /*
>           * There is no use in forwarding any barrier request since we can't
>           * guarantee it is (or can be) handled by the targets correctly.
>           */ 
That seems weird. I thought one of the reasons for having stacked block devices
is that you could pass on barrier requests.

I have seen comments about adding barrier support to linear block devices
that currently don't support it (e.g. dmcrypt) relatively recently.

On a somewhat related note there was a discussion about issues with barriers
on lmkl last February that suggested there are issues with sync on linux
if you have write cache enabled even if you are using barriers.

LVM negates benefits of jounaling filesystems? [was RFE: autofsck]

[Eric Sandeen]

Bruno Wolff III wrote:
>  On Tue, Jun 10, 2008 at 09:49:16 -0500,
>    Eric Sandeen <sandeen(a)redhat.com&gt; wrote:
> > LVM barriers aren't so much broken as simply un-implemented by design.
> >
> > static int dm_request(struct request_queue *q, struct bio *bio)
> > {
> > ...
> >         /*
> >          * There is no use in forwarding any barrier request since we can't
> >          * guarantee it is (or can be) handled by the targets correctly.
> >          */
>  
>  That seems weird. I thought one of the reasons for having stacked block devices
>  is that you could pass on barrier requests. 
Not really; in general it is trickier w/ more devices I think.

md for example passes barriers on raid1 but not 0 or 5 AFAIK...

>  I have seen comments about adding barrier support to linear block
> devices
>  that currently don't support it (e.g. dmcrypt) relatively recently.
>  
>  On a somewhat related note there was a discussion about issues with barriers
>  on lmkl last February that suggested there are issues with sync on linux
>  if you have write cache enabled even if you are using barriers. 
Got a url?

Thanks,
-Eric

LVM negates benefits of jounaling filesystems? [was RFE: autofsck]

[Bruno Wolff III]

On Tue, Jun 10, 2008 at 11:02:02 -0500,
  Eric Sandeen <sandeen(a)redhat.com&gt; wrote:
>  
>  md for example passes barriers on raid1 but not 0 or 5 AFAIK... 
I have heard that, but not verified it myself. I am not sure why this is the
case as I wouldn't expect doing raid 1 to be that much easier than other
types of raid.

>  Got a url? 
This is a LWN article pointing to the start of a lmkl thread with the
title: "Proposal for "proper" durable fsync() and fdatasync()"
http://lwn.net/Articles/270891/

LVM negates benefits of jounaling filesystems? [was RFE: autofsck]

[max]

On Tue, Jun 10, 2008 at 9:46 AM, Chuck Anderson <cra(a)wpi.edu&gt; wrote:
>  On Tue, Jun 10, 2008 at 08:36:31AM -0500, Eric Sandeen wrote:
> > journaling filesystem you really shouldn't have any filesystem metadata
> > integrity problems on power loss; that is, if you have barriers on
> > (which ext3 doesn't by default) and if your storage can pass barriers
> > (which lvm doesn't), or if you have drive write cache disabled (which
> > hurts performance pretty badly).
>
>  I wasn't aware that LVM destroyed the kind of guarantees about
>  filesystem metadata being written out to disk that jounaling
>  filesystems rely on?  If so, should we perhaps rethink the decision to
>  use LVM by default on Fedora installs?
>  
What was the reason for using LVM in the first place. My most recent
install I was really tempted to not go with the defaults but because I
really don't know much about filesystems, I figured the best thing in
that case was stick to the defaults. Now I am reconsidering
again...could someone explain the comparative advantages/disadvantages
? Before i do something stupid .


-- 
If opinions were really like assholes we'd each have just one

LVM negates benefits of jounaling filesystems? [was RFE: autofsck]

[Andrew Haley]

max bianco wrote:
>  On Tue, Jun 10, 2008 at 9:46 AM, Chuck Anderson <cra(a)wpi.edu&gt;
> wrote:
> > On Tue, Jun 10, 2008 at 08:36:31AM -0500, Eric Sandeen wrote:
> >> journaling filesystem you really shouldn't have any filesystem metadata
> >> integrity problems on power loss; that is, if you have barriers on
> >> (which ext3 doesn't by default) and if your storage can pass barriers
> >> (which lvm doesn't), or if you have drive write cache disabled (which
> >> hurts performance pretty badly).
> > I wasn't aware that LVM destroyed the kind of guarantees about
> > filesystem metadata being written out to disk that jounaling
> > filesystems rely on?  If so, should we perhaps rethink the decision to
> > use LVM by default on Fedora installs?
> >
>  
>  What was the reason for using LVM in the first place. My most recent
>  install I was really tempted to not go with the defaults but because I
>  really don't know much about filesystems, I figured the best thing in
>  that case was stick to the defaults. Now I am reconsidering
>  again...could someone explain the comparative advantages/disadvantages
>  ? Before i do something stupid . 
LVM has a lot of advantages with regard to flexibility: you can add a
disk to a filesystem, for example.  It has a lot of nice features.

Andrew.

LVM negates benefits of jounaling filesystems? [was RFE: autofsck]

[max]

On Tue, Jun 10, 2008 at 4:38 PM, Andrew Haley <aph(a)redhat.com&gt; wrote:
>  max bianco wrote:
> > On Tue, Jun 10, 2008 at 9:46 AM, Chuck Anderson <cra(a)wpi.edu&gt; wrote:
> >> On Tue, Jun 10, 2008 at 08:36:31AM -0500, Eric Sandeen wrote:
> >>> journaling filesystem you really shouldn't have any filesystem metadata
> >>> integrity problems on power loss; that is, if you have barriers on
> >>> (which ext3 doesn't by default) and if your storage can pass barriers
> >>> (which lvm doesn't), or if you have drive write cache disabled (which
> >>> hurts performance pretty badly).
> >> I wasn't aware that LVM destroyed the kind of guarantees about
> >> filesystem metadata being written out to disk that jounaling
> >> filesystems rely on?  If so, should we perhaps rethink the decision to
> >> use LVM by default on Fedora installs?
> >>
> >
> > What was the reason for using LVM in the first place. My most recent
> > install I was really tempted to not go with the defaults but because I
> > really don't know much about filesystems, I figured the best thing in
> > that case was stick to the defaults. Now I am reconsidering
> > again...could someone explain the comparative advantages/disadvantages
> > ? Before i do something stupid .
>
>  LVM has a lot of advantages with regard to flexibility: you can add a
>  disk to a filesystem, for example.  It has a lot of nice features.
>
>  Andrew.
>  
but there seems to be some question as to data integrity or ability to
recover data in the event of disaster or am i reading too much into
this?


-- 
If opinions were really like assholes we'd each have just one

LVM negates benefits of jounaling filesystems? [was RFE: autofsck]

[Andrew Haley]

max bianco wrote:
>  On Tue, Jun 10, 2008 at 4:38 PM, Andrew Haley <aph(a)redhat.com&gt;
> wrote:
> > max bianco wrote:
> >> On Tue, Jun 10, 2008 at 9:46 AM, Chuck Anderson <cra(a)wpi.edu&gt; wrote:
> >>> On Tue, Jun 10, 2008 at 08:36:31AM -0500, Eric Sandeen wrote:
> >>>> journaling filesystem you really shouldn't have any filesystem
> metadata
> >>>> integrity problems on power loss; that is, if you have barriers on
> >>>> (which ext3 doesn't by default) and if your storage can pass
> barriers
> >>>> (which lvm doesn't), or if you have drive write cache disabled
> (which
> >>>> hurts performance pretty badly).
> >>> I wasn't aware that LVM destroyed the kind of guarantees about
> >>> filesystem metadata being written out to disk that jounaling
> >>> filesystems rely on?  If so, should we perhaps rethink the decision to
> >>> use LVM by default on Fedora installs?
> >>>
> >> What was the reason for using LVM in the first place. My most recent
> >> install I was really tempted to not go with the defaults but because I
> >> really don't know much about filesystems, I figured the best thing in
> >> that case was stick to the defaults. Now I am reconsidering
> >> again...could someone explain the comparative advantages/disadvantages
> >> ? Before i do something stupid .
> > LVM has a lot of advantages with regard to flexibility: you can add a
> > disk to a filesystem, for example.  It has a lot of nice features. 
>  but there seems to be some question as to data integrity or ability
> to
>  recover data in the event of disaster or am i reading too much into
>  this? 
Yes, you are.  The question here is about barriers, which are off by
default in ext3 anyway.  If you're worried about disaster recovery, you
need to be looking at backup and replication.

Andrew.

LVM negates benefits of jounaling filesystems? [was RFE: autofsck]

[max]

Andrew Haley wrote:
>  max bianco wrote:
> > On Tue, Jun 10, 2008 at 4:38 PM, Andrew Haley <aph(a)redhat.com&gt; wrote:
> >> max bianco wrote:
> >>> On Tue, Jun 10, 2008 at 9:46 AM, Chuck Anderson <cra(a)wpi.edu&gt; wrote:
> >>>> On Tue, Jun 10, 2008 at 08:36:31AM -0500, Eric Sandeen wrote:
> >>>>> journaling filesystem you really shouldn't have any filesystem
> metadata
> >>>>> integrity problems on power loss; that is, if you have barriers on
> >>>>> (which ext3 doesn't by default) and if your storage can pass
> barriers
> >>>>> (which lvm doesn't), or if you have drive write cache disabled
> (which
> >>>>> hurts performance pretty badly).
> >>>> I wasn't aware that LVM destroyed the kind of guarantees about
> >>>> filesystem metadata being written out to disk that jounaling
> >>>> filesystems rely on?  If so, should we perhaps rethink the decision to
> >>>> use LVM by default on Fedora installs?
> >>>>
> >>> What was the reason for using LVM in the first place. My most recent
> >>> install I was really tempted to not go with the defaults but because I
> >>> really don't know much about filesystems, I figured the best thing in
> >>> that case was stick to the defaults. Now I am reconsidering
> >>> again...could someone explain the comparative advantages/disadvantages
> >>> ? Before i do something stupid .
> >> LVM has a lot of advantages with regard to flexibility: you can add a
> >> disk to a filesystem, for example.  It has a lot of nice features.
>  
> > but there seems to be some question as to data integrity or ability to
> > recover data in the event of disaster or am i reading too much into
> > this?
>  
>  Yes, you are.  The question here is about barriers, which are off by
>  default in ext3 anyway.  If you're worried about disaster recovery, you
>  need to be looking at backup and replication.
>  
>  Andrew.
>   
I am the victim of the poorly worded question, due entirely to my own 
ignorance on the subject but I did a little poking around so I'll have 
another go at it. Is disaster recovery more difficult with an LVM than 
the older standard partioning scheme?

-- 
Revenge is for the ignorant

LVM negates benefits of jounaling filesystems? [was RFE: autofsck]

[max]

On Tue, Jun 10, 2008 at 4:38 PM, Andrew Haley <aph(a)redhat.com&gt; wrote:
>  max bianco wrote:
> > On Tue, Jun 10, 2008 at 9:46 AM, Chuck Anderson <cra(a)wpi.edu&gt; wrote:
> >> On Tue, Jun 10, 2008 at 08:36:31AM -0500, Eric Sandeen wrote:
> >>> journaling filesystem you really shouldn't have any filesystem metadata
> >>> integrity problems on power loss; that is, if you have barriers on
> >>> (which ext3 doesn't by default) and if your storage can pass barriers
> >>> (which lvm doesn't), or if you have drive write cache disabled (which
> >>> hurts performance pretty badly).
> >> I wasn't aware that LVM destroyed the kind of guarantees about
> >> filesystem metadata being written out to disk that jounaling
> >> filesystems rely on?  If so, should we perhaps rethink the decision to
> >> use LVM by default on Fedora installs?
> >>
> >
> > What was the reason for using LVM in the first place. My most recent
> > install I was really tempted to not go with the defaults but because I
> > really don't know much about filesystems, I figured the best thing in
> > that case was stick to the defaults. Now I am reconsidering
> > again...could someone explain the comparative advantages/disadvantages
> > ? Before i do something stupid .
>
>  LVM has a lot of advantages with regard to flexibility: you can add a
>  disk to a filesystem, for example.  It has a lot of nice features.
>
>  Andrew.
>  
but there seems to be some question as to data integrity or ability to
recover data in the event of disaster or am i reading too much into
this? Just a pointer to a good source of current info would be enough
, if someone has a bookmark, i don't mind doing my own homework but
sometimes I find too much opinion and not enough fact. Just a good
starting place , if someone would be so kind.


-- 
If opinions were really like assholes we'd each have just one

LVM negates benefits of jounaling filesystems? [was RFE: autofsck]

[Michel Salim]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

max bianco wrote:

>  What was the reason for using LVM in the first place. My most recent
>  install I was really tempted to not go with the defaults but because I
>  really don't know much about filesystems, I figured the best thing in
>  that case was stick to the defaults. Now I am reconsidering
>  again...could someone explain the comparative advantages/disadvantages
>  ? Before i do something stupid .
>   
It's hard to go completely with the defaults, which does not specify a
separate partition for home directories too.

- --
Michel
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
> Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
>
> iEYEARECAAYFAkhRTOYACgkQWt0J3fd+7ZBnywCcCbFLRF6zYRKhy3Kawhxoi4He
> 8I0An2YgsCbsNBoNABTWDeyjRtfrB/kU
> =WJ83
> -----END PGP SIGNATURE-----

LVM negates benefits of jounaling filesystems? [was RFE: autofsck]

[max]

On Thu, Jun 12, 2008 at 12:20 PM, Michel Salim <michel.sylvan(a)gmail.com&gt; wrote:
>  -----BEGIN PGP SIGNED MESSAGE-----
>  Hash: SHA1
>
>  max bianco wrote:
>
> > What was the reason for using LVM in the first place. My most recent
> > install I was really tempted to not go with the defaults but because I
> > really don't know much about filesystems, I figured the best thing in
> > that case was stick to the defaults. Now I am reconsidering
> > again...could someone explain the comparative advantages/disadvantages
> > ? Before i do something stupid .
> >
>  It's hard to go completely with the defaults, which does not specify a
>  separate partition for home directories too.
>  
I didn't phrase that right. The default is an LVM though, i understand
the advantages and i keep a back up so I am not going to repartition
the drive but if its harder to recover data from an LVM then I may
avoid using that scheme in the future.

[Ahmed Kamal]

I totally agree we should fix the core cause. If there's anything to prevent
file system errors from ever happening, go for it. However, when the
inevitable
Filesystem errors, Fix(y/n):
appears, when was the last time you pressed "n"! Unless you're Theodore tso
there's not so much you could do, eh! So why not make that the default

On Tue, Jun 10, 2008 at 4:36 PM, Eric Sandeen <sandeen(a)redhat.com&gt; wrote:

>  Ahmed Kamal wrote:
>  > I would like to propose
>  >
>  > echo AUTOFSCK_DEF_CHECK=yes >> /etc/sysconfig/autofsck
>  > echo 'AUTOFSCK_OPT="-y"' >> /etc/sysconfig/autofsck
>  >
>  > Working with a local ISP in some rural area where there's a lot of power
>  > cuts! The ISP guys were asking like, "Why is it that Linux boxes need
>  > manual intervention to get back up after a power cut!" .. "Can't you
>  > script what you're doing to get it back up" ?!
>  > Does not having this as the default makes sense in some tangible number
>  > of cases ?!
>  >
>
>  Adding -y could potentially be dangerous.  e2fsck asks when the answer
>  isn't obvious.  In some situations, perhaps, but I probably would not
>  make this default.
>
>  I'm more concerned that you're seeing so many problems; with a
>  journaling filesystem you really shouldn't have any filesystem metadata
>  integrity problems on power loss; that is, if you have barriers on
>  (which ext3 doesn't by default) and if your storage can pass barriers
>  (which lvm doesn't), or if you have drive write cache disabled (which
>  hurts performance pretty badly).
>
>  I'd rather address the root of the problem and sort out why, if you are
>  paying the journaling overhead penalty at runtime, it's not saving you
>  on power loss.
>
>  -Eric
>
>  --
>  fedora-devel-list mailing list
>  fedora-devel-list(a)redhat.com
>  https://www.redhat.com/mailman/listinfo/fedora-devel-list
>

[Eric Sandeen]

Ahmed Kamal wrote:
>  I totally agree we should fix the core cause. If there's anything
> to
>  prevent file system errors from ever happening, go for it. However, when
>  the inevitable
>  Filesystem errors, Fix(y/n):
>  appears, when was the last time you pressed "n"! Unless you're Theodore
>  tso there's not so much you could do, eh! So why not make that the default 
For the same reason that Ted T'so doesn't think the software itself
should blindly assume -y as the default.  ;)  You are basically asking
the Fedora scripts to override the e2fsck defaults chosen by Ted as the
safest approach.

If nothing else, forcing the user to press "y" at least alerts them that
something  has gone wrong.  An unattended box rebooting post-disaster,
running e2fsck -y may move huge swaths of data to lost+found
automatically and leave the user scratching their heads about where on
earth all their email went (or whatever).

If you like the tradeoff by all means set it on your boxes, it may be
the right answer in your situation, but I don't like it for a default.

-Eric

[Bill Crawford]

2008/6/10 Eric Sandeen <sandeen(a)redhat.com&gt;:

>  For the same reason that Ted T'so doesn't think the software
> itself
>  should blindly assume -y as the default.  ;)  You are basically asking
>  the Fedora scripts to override the e2fsck defaults chosen by Ted as the
>  safest approach. 
Would making "-p" the default be an acceptable compromise?
 [I thought we used to do this, but I could be losing my marbles]

[Paul Wouters]

>  For the same reason that Ted T'so doesn't think the software
> itself
>  should blindly assume -y as the default.  ;)  You are basically asking
>  the Fedora scripts to override the e2fsck defaults chosen by Ted as the
>  safest approach. 
Who, aside from Ted Tso, can do anything else but re-run with "yes"? You
are just postponing the problem, and thereby adding to the problem.

>  If nothing else, forcing the user to press "y" at least
> alerts them that
>  something  has gone wrong. 
We already know something is wrong, our box is missing waiting in single
user mode.

>   An unattended box rebooting post-disaster,
>  running e2fsck -y may move huge swaths of data to lost+found
>  automatically and leave the user scratching their heads about where on
>  earth all their email went (or whatever). 
As compared to rebooting post-disaster, being gone, needing the sysadmin
to drive over, find single user mode, run e2fsck, get INCONSISTENT
FILESYSTEM detected, and rerun with e2fsck -y, which puts all files in
lost+found.

How different your scenario from having "-y" or not? Nothing.

However, on the OTHER 99.99% of the scnearios, your box is dead in the
water and boxes with -y are back online. I'd rather scratch my head on
a missing email. Besides, if THAT is what you want to fix, then fix
that by warning the user/root/wheel group upon login if there are files
in lost+found.

>  If you like the tradeoff by all means set it on your boxes, it may
> be
>  the right answer in your situation, but I don't like it for a default. 
You're wrong. I had a discussion with Ted himself who sees that the
current way is wrong. You can find me ranting every fedora release that
it is wrong. I run boxes all over the planet, from RH9 to F9 and RHEL.
It's a problem. It's always been a problem.

What would help is to add /etc/sysconfig/autofsck with the line

 	# AUTOFSCK_OPT="-y"

so at least we don't have to keep reading rc.sysvinit to figure out which
version of fedora we need to change which script/variable to make this
happen.

Though personally, I'd prefer an Anaconda option for it.

 	"Unselect this option if you want to disable automatic repair
 	 attempts of the filesystem, and have a chance to use a
 	 raw filesystem editor to directly edit raw blocks on disk"

Let's face it. There are 10 people in the world who could and maybe want,
to do this to an ext3 filesystem, and I'm pretty sure they maintain less
then 0.00001% of the Fedora servers ouf there.

Paul

[Eric Sandeen]

Paul Wouters wrote:


>  You're wrong. I had a discussion with Ted himself who sees that
> the
>  current way is wrong.  
If Ted thinks it's wrong, perhaps he would accept a patch to make -y the
default instead of having distros work around the upstream defaults via
scripts?

>  What would help is to add /etc/sysconfig/autofsck with the line
>  
>   	# AUTOFSCK_OPT="-y"
>  
>  so at least we don't have to keep reading rc.sysvinit to figure out which
>  version of fedora we need to change which script/variable to make this
>  happen. 
Yep, I agree that if scripts are looking for magic sysconfig files they
should probably exist at least as placeholders...

-Eric

[Alan Cox]

On Tue, Jun 10, 2008 at 12:30:53PM -0400, Paul Wouters wrote:
>  Who, aside from Ted Tso, can do anything else but re-run with
> "yes"? You
>  are just postponing the problem, and thereby adding to the problem. 
Most users.

>  Though personally, I'd prefer an Anaconda option for it.
>  
>  	"Unselect this option if you want to disable automatic repair
>  	 attempts of the filesystem, and have a chance to use a
>  	 raw filesystem editor to directly edit raw blocks on disk" 
That would suck. For most users you might as well ask them if they wanted
frobnicate the meta-haddock.

>  Let's face it. There are 10 people in the world who could and
> maybe want,
>  to do this to an ext3 filesystem, and I'm pretty sure they maintain less
>  then 0.00001% of the Fedora servers ouf there. 
There are lots of cases you want that thing to stop. For example if there is
important data on the box and you decide to get advice first. If you follow
the most basic single rule of recovering a damaged file system you want it
to stop so you can make a copy. Indeed you may well need a professional recovery
expert or have a support contract and need to ask the helpdesk...

-y in some cases is also things like:
	"Destroy any hope of recovering your PhD Thesis"

Alan

[Paul Wouters]

On Tue, 10 Jun 2008, Alan Cox wrote:

>  Date: Tue, 10 Jun 2008 13:36:02 -0400
>  From: Alan Cox <alan(a)redhat.com&gt;
>  To: Development discussions related to Fedora <fedora-devel-list(a)redhat.com&gt;
>  Subject: Re: RFE: autofsck
>  
>  On Tue, Jun 10, 2008 at 12:30:53PM -0400, Paul Wouters wrote:
> > Who, aside from Ted Tso, can do anything else but re-run with "yes"? You
> > are just postponing the problem, and thereby adding to the problem.
>
>  Most users. 
Right. Most users can't even use a command line, let alone a raw disk editor.

> > Though personally, I'd prefer an Anaconda option for it.
> >
> > 	"Unselect this option if you want to disable automatic repair
> > 	 attempts of the filesystem, and have a chance to use a
> > 	 raw filesystem editor to directly edit raw blocks on disk"
>
>  That would suck. For most users you might as well ask them if they wanted
>  frobnicate the meta-haddock. 
Indeed. We agree there. Hence "unselect". Let's assume that users who
don't
know what frobinating a meta-haddock is, will stick to defaults :)

>  There are lots of cases you want that thing to stop. For example if
> there is
>  important data on the box and you decide to get advice first. If you follow
>  the most basic single rule of recovering a damaged file system you want it
>  to stop so you can make a copy. Indeed you may well need a professional recovery
>  expert or have a support contract and need to ask the helpdesk... 
How many people on this list have:

a) paid for root filesystem data recovery
b) answered "no" and hand edited the root fs?

>  -y in some cases is also things like:
>  	"Destroy any hope of recovering your PhD Thesis" 
Don't story your PhD on your root fs. Also, if you want to protect against PhD
thesis for normal users, you should make root's "rm" alias a global
setting.

Just to remind you, what people have a problem with is not running manual
fsck's on certain filesystems. People have a problem with machines being stuck
in single user mode waiting for manual intervention leading "fsck -y" anyway
on the root filesystem.

If my remote machine comes back, starts sshd, and then has /home not mounted
because of an INCOSISTENCT FILESYSTEM error, I'm more then happy to run fsck -y
manually.

Paul

[Eric Sandeen]

Paul Wouters wrote:

>  Just to remind you, what people have a problem with is not running
> manual
>  fsck's on certain filesystems. People have a problem with machines being stuck
>  in single user mode waiting for manual intervention leading "fsck -y" anyway
>  on the root filesystem.
>  
>  If my remote machine comes back, starts sshd, and then has /home not mounted
>  because of an INCOSISTENCT FILESYSTEM error, I'm more then happy to run fsck -y
>  manually. 
As a bit of a tangent, if you see this fairly often, any idea why?
Journaling should in general protect you from needing any sort of fsck
after a power loss or oops; that's what they're for, right.  I'd be
curious to know what sorts of corruptions you wind up finding.

How the corruption gets coped with once found is one point worth
discussing, but where's it coming from in the first place?  My guess is
it's lack of barrier writes, but it's worth getting to the bottom of it,
and hopefully this will make the choice of e2fsck parameters less
relevant.  :)

-Eric

[Ahmed Kamal]

Since on similar topics we could argue forever, is it reasonable to have a
poll system where devs/users would vote on such questions like should such a
feature be the default or not ?

On Tue, Jun 10, 2008 at 9:32 PM, Eric Sandeen <sandeen(a)redhat.com&gt; wrote:

>  Paul Wouters wrote:
>
>  > Just to remind you, what people have a problem with is not running manual
>  > fsck's on certain filesystems. People have a problem with machines being
>  stuck
>  > in single user mode waiting for manual intervention leading "fsck -y"
>  anyway
>  > on the root filesystem.
>  >
>  > If my remote machine comes back, starts sshd, and then has /home not
>  mounted
>  > because of an INCOSISTENCT FILESYSTEM error, I'm more then happy to run
>  fsck -y
>  > manually.
>
>  As a bit of a tangent, if you see this fairly often, any idea why?
>  Journaling should in general protect you from needing any sort of fsck
>  after a power loss or oops; that's what they're for, right.  I'd be
>  curious to know what sorts of corruptions you wind up finding.
>
>  How the corruption gets coped with once found is one point worth
>  discussing, but where's it coming from in the first place?  My guess is
>  it's lack of barrier writes, but it's worth getting to the bottom of it,
>  and hopefully this will make the choice of e2fsck parameters less
>  relevant.  :)
>
>  -Eric
>
>  --
>  fedora-devel-list mailing list
>  fedora-devel-list(a)redhat.com
>  https://www.redhat.com/mailman/listinfo/fedora-devel-list
>

[Bill Nottingham]

Ahmed Kamal (email.ahmedkamal(a)googlemail.com) said: 
>  Since on similar topics we could argue forever, is it reasonable to
> have a
>  poll system where devs/users would vote on such questions like should such a
>  feature be the default or not ? 
I'm fairly sure voting for features is a rather bad idea.

Bill

[Paul Wouters]

On Tue, 10 Jun 2008, Eric Sandeen wrote:

> > because of an INCOSISTENCT FILESYSTEM error, I'm more then
> happy to run fsck -y
> > manually.
>
>  As a bit of a tangent, if you see this fairly often, any idea why? 
Not "fairly often", but enough to get upset about the missing "-y"
option

>  Journaling should in general protect you from needing any sort of
> fsck
>  after a power loss or oops; that's what they're for, right.  I'd be
>  curious to know what sorts of corruptions you wind up finding. 
I honestly don't remember what kind of errors. It tends to happen on
machines for uptimes of > 1 year, so it could be either known bugs in
the kernel or some bad ram/write. A few years ago, I had all servers
that rebooted fail to find an MBR, apparently some bug had caused writes
to the start of the disk. I ended up running (then lilo) on various
machines just to be sure. From what I remember, the inconsistency
errors tend to be minor (a few lines of errors). The disks that grind
most of the fs into lost+found tend to be experimental/development
servers that reside in my office.

Paul

[Alan Cox]

On Tue, Jun 10, 2008 at 02:24:55PM -0400, Paul Wouters wrote:
>  a) paid for root filesystem data recovery
>  b) answered "no" and hand edited the root fs? 
I've provided help to people rescuing their root fs and other fs on mailing
lists. The local LUG has likewise

>  thesis for normal users, you should make root's "rm"
> alias a global setting. 
nautilus warns and has a track can

>  If my remote machine comes back, starts sshd, and then has /home not
> mounted
>  because of an INCOSISTENCT FILESYSTEM error, I'm more then happy to run 
>  fsck -y
>  manually. 
And those who know enough to pick that option know enough to set it. The
reverse is not true.

[Callum Lerwick]

2008/6/10 Ahmed Kamal <email.ahmedkamal(a)googlemail.com&gt;:

>  Working with a local ISP in some rural area where there's a lot
> of power
>  cuts! The ISP guys were asking like, "Why is it that Linux boxes need manual
>  intervention to get back up after a power cut!" .. "Can't you script what
>  you're doing to get it back up" ?!
>  Does not having this as the default makes sense in some tangible number of
>  cases ?! 

Seems to me the obvious question is, if you are an ISP and you have a known
problem with power dropouts, why are all these boxes not on UPSs and rigged
to shut themselves down properly on power fail?

... Not that this is an excuse for journaling not doing its job.