Hi!
> > I guess I should try to measure it. (Linux already does writeback
> > caching, with 2GB of memory. I wonder how important disks's 2MB of
> > cache can be).
>
> It serves essentially the same purpose as the 'async' option in /etc/exports
> (i.e. we declare it "done" when the other end of
Hi!
I guess I should try to measure it. (Linux already does writeback
caching, with 2GB of memory. I wonder how important disks's 2MB of
cache can be).
It serves essentially the same purpose as the 'async' option in /etc/exports
(i.e. we declare it done when the other end of the wire
I just had a talk with a colleague, John Palmer, who worked on disk drive
design for about 5 years in the '90s and he gave me a very confident,
credible explanation of some of the things we've been wondering about disk
drive power loss in this thread, complete with demonstrations of various
Ric Wheeler wrote:
Theodore Tso wrote:
On Thu, Jan 17, 2008 at 04:31:48PM -0800, Bryan Henderson wrote:
But I heard some years ago from a disk drive engineer that that is a
myth just like the rotational energy thing. I added that to the
discussion, but admitted that I haven't actually seen a
"H. Peter Anvin" <[EMAIL PROTECTED]> wrote on 01/18/2008 07:08:30 AM:
> Bryan Henderson wrote:
> >
> > We weren't actually talking about writing out the cache. While that
was
> > part of an earlier thread which ultimately conceded that disk drives
most
> > probably do not use the spinning
Theodore Tso wrote:
On Thu, Jan 17, 2008 at 04:31:48PM -0800, Bryan Henderson wrote:
But I heard some years ago from a disk drive engineer that that is a myth
just like the rotational energy thing. I added that to the discussion,
but admitted that I haven't actually seen a disk drive write a
Bryan Henderson wrote:
We weren't actually talking about writing out the cache. While that was
part of an earlier thread which ultimately conceded that disk drives most
probably do not use the spinning disk energy to write out the cache, the
claim was then made that the drive at least
On Thu, Jan 17, 2008 at 04:31:48PM -0800, Bryan Henderson wrote:
> But I heard some years ago from a disk drive engineer that that is a myth
> just like the rotational energy thing. I added that to the discussion,
> but admitted that I haven't actually seen a disk drive write a partial
>
Bryan Henderson wrote:
We weren't actually talking about writing out the cache. While that was
part of an earlier thread which ultimately conceded that disk drives most
probably do not use the spinning disk energy to write out the cache, the
claim was then made that the drive at least
On Thu, Jan 17, 2008 at 04:31:48PM -0800, Bryan Henderson wrote:
But I heard some years ago from a disk drive engineer that that is a myth
just like the rotational energy thing. I added that to the discussion,
but admitted that I haven't actually seen a disk drive write a partial
sector.
H. Peter Anvin [EMAIL PROTECTED] wrote on 01/18/2008 07:08:30 AM:
Bryan Henderson wrote:
We weren't actually talking about writing out the cache. While that
was
part of an earlier thread which ultimately conceded that disk drives
most
probably do not use the spinning disk energy to
I just had a talk with a colleague, John Palmer, who worked on disk drive
design for about 5 years in the '90s and he gave me a very confident,
credible explanation of some of the things we've been wondering about disk
drive power loss in this thread, complete with demonstrations of various
Ric Wheeler wrote:
Theodore Tso wrote:
On Thu, Jan 17, 2008 at 04:31:48PM -0800, Bryan Henderson wrote:
But I heard some years ago from a disk drive engineer that that is a
myth just like the rotational energy thing. I added that to the
discussion, but admitted that I haven't actually seen a
Theodore Tso wrote:
On Thu, Jan 17, 2008 at 04:31:48PM -0800, Bryan Henderson wrote:
But I heard some years ago from a disk drive engineer that that is a myth
just like the rotational energy thing. I added that to the discussion,
but admitted that I haven't actually seen a disk drive write a
Ric Wheeler <[EMAIL PROTECTED]> wrote on 01/17/2008 03:18:05 PM:
> Theodore Tso wrote:
> > On Wed, Jan 16, 2008 at 09:02:50PM -0500, Daniel Phillips wrote:
> >> Have you observed that in the wild? A former engineer of a disk
drive
> >> company suggests to me that the capacitors on the board
Theodore Tso wrote:
On Wed, Jan 16, 2008 at 09:02:50PM -0500, Daniel Phillips wrote:
Have you observed that in the wild? A former engineer of a disk drive
company suggests to me that the capacitors on the board provide enough
power to complete the last sector, even to park the head.
Even if
> interrupt which caused the Irix to run around frantically shutting
> down DMA's for a controlled shutdown. Of course, PC-class hardware
> has none of this. My source for this was Jim Mostek, one of the
PC class hardware has a power good signal which drops just before the
rest.
--
To
On Jan 17, 2008 7:29 AM, Szabolcs Szakacsits <[EMAIL PROTECTED]> wrote:
> Similarly to ZFS, Windows Server 2008 also has self-healing NTFS:
I guess that is enough votes to justify going ahead and trying an
implementation of the reverse mapping ideas I posted. But of course
more votes for this is
On Wed, Jan 16, 2008 at 09:02:50PM -0500, Daniel Phillips wrote:
>
> Have you observed that in the wild? A former engineer of a disk drive
> company suggests to me that the capacitors on the board provide enough
> power to complete the last sector, even to park the head.
>
The problem isn't
"Daniel Phillips" <[EMAIL PROTECTED]> wrote on 01/16/2008 06:02:50 PM:
> On Jan 16, 2008 2:06 PM, Bryan Henderson <[EMAIL PROTECTED]> wrote:
> > >The "disk motor as a generator" tale may not be purely folklore. When
> > >an IDE drive is not in writeback mode, something special needs to
done
> >
On Tue 2008-01-15 20:36:16, Chris Mason wrote:
> On Tue, 15 Jan 2008 20:24:27 -0500
> "Daniel Phillips" <[EMAIL PROTECTED]> wrote:
>
> > On Jan 15, 2008 7:15 PM, Alan Cox <[EMAIL PROTECTED]> wrote:
> > > > Writeback cache on disk in iteself is not bad, it only gets bad
> > > > if the disk is not
On Tue, 15 Jan 2008, Daniel Phillips wrote:
> Along with this effort, could you let me know if the world actually
> cares about online fsck? Now we know how to do it I think, but is it
> worth the effort.
Most users seem to care deeply about "things just work". Here is why
ntfs-3g also took
On Tue, 15 Jan 2008, Daniel Phillips wrote:
Along with this effort, could you let me know if the world actually
cares about online fsck? Now we know how to do it I think, but is it
worth the effort.
Most users seem to care deeply about things just work. Here is why
ntfs-3g also took the
On Tue 2008-01-15 20:36:16, Chris Mason wrote:
On Tue, 15 Jan 2008 20:24:27 -0500
Daniel Phillips [EMAIL PROTECTED] wrote:
On Jan 15, 2008 7:15 PM, Alan Cox [EMAIL PROTECTED] wrote:
Writeback cache on disk in iteself is not bad, it only gets bad
if the disk is not engineered to save
Daniel Phillips [EMAIL PROTECTED] wrote on 01/16/2008 06:02:50 PM:
On Jan 16, 2008 2:06 PM, Bryan Henderson [EMAIL PROTECTED] wrote:
The disk motor as a generator tale may not be purely folklore. When
an IDE drive is not in writeback mode, something special needs to
done
to ensure the
On Jan 17, 2008 7:29 AM, Szabolcs Szakacsits [EMAIL PROTECTED] wrote:
Similarly to ZFS, Windows Server 2008 also has self-healing NTFS:
I guess that is enough votes to justify going ahead and trying an
implementation of the reverse mapping ideas I posted. But of course
more votes for this is
On Wed, Jan 16, 2008 at 09:02:50PM -0500, Daniel Phillips wrote:
Have you observed that in the wild? A former engineer of a disk drive
company suggests to me that the capacitors on the board provide enough
power to complete the last sector, even to park the head.
The problem isn't with
Ric Wheeler [EMAIL PROTECTED] wrote on 01/17/2008 03:18:05 PM:
Theodore Tso wrote:
On Wed, Jan 16, 2008 at 09:02:50PM -0500, Daniel Phillips wrote:
Have you observed that in the wild? A former engineer of a disk
drive
company suggests to me that the capacitors on the board provide
Theodore Tso wrote:
On Wed, Jan 16, 2008 at 09:02:50PM -0500, Daniel Phillips wrote:
Have you observed that in the wild? A former engineer of a disk drive
company suggests to me that the capacitors on the board provide enough
power to complete the last sector, even to park the head.
Even if
interrupt which caused the Irix to run around frantically shutting
down DMA's for a controlled shutdown. Of course, PC-class hardware
has none of this. My source for this was Jim Mostek, one of the
PC class hardware has a power good signal which drops just before the
rest.
--
To unsubscribe
On Jan 15, 2008 22:05 -0500, Rik van Riel wrote:
> With a filesystem that is compartmentalized and checksums metadata,
> I believe that an online fsck is absolutely worth having.
>
> Instead of the filesystem resorting to mounting the whole volume
> read-only on certain errors, part of the
On Jan 16, 2008 2:06 PM, Bryan Henderson <[EMAIL PROTECTED]> wrote:
> >The "disk motor as a generator" tale may not be purely folklore. When
> >an IDE drive is not in writeback mode, something special needs to done
> >to ensure the last write to media is not a scribble.
>
> No it doesn't. The
Alan Cox wrote:
>> Writeback cache on disk in iteself is not bad, it only gets bad if the
>> disk is not engineered to save all its dirty cache on power loss,
>> using the disk motor as a generator or alternatively a small battery.
>> It would be awfully nice to know which brands fail here, if
On Jan 16, 2008 3:49 AM, Pavel Machek <[EMAIL PROTECTED]> wrote:
>
> ext3's "lets fsck on every 20 mounts" is good idea, but it can be
> annoying when developing. Having option to fsck while filesystem is
> online takes that annoyance away.
I'm sure everyone on cc: knows this, but for the record
> And I think there's a problem with drives that, upon sensing the
> unreadable sector, assign an alternate even though the sector is fine, and
> you eventually run out of spares.
You are assuming drives can't tell the difference between stray data loss
and sectors that can't be recovered by
>The "disk motor as a generator" tale may not be purely folklore. When
>an IDE drive is not in writeback mode, something special needs to done
>to ensure the last write to media is not a scribble.
No it doesn't. The last write _is_ a scribble. Systems that make atomic
updates to disk drives
On Wed, Jan 16, 2008 at 08:43:25AM +1100, David Chinner wrote:
> ext3 is not the only filesystem that will have trouble due to
> volatile write caches. We see problems often enough with XFS
> due to volatile write caches that it's in our FAQ:
In fact it will hit every filesystem. A write-back
On Wed, 16 Jan 2008 12:51:44 +0100, Pavel Machek said:
> I guess I should try to measure it. (Linux already does writeback
> caching, with 2GB of memory. I wonder how important disks's 2MB of
> cache can be).
It serves essentially the same purpose as the 'async' option in /etc/exports
(i.e. we
On Tue 2008-01-15 18:44:26, Daniel Phillips wrote:
> On Jan 15, 2008 6:07 PM, Pavel Machek <[EMAIL PROTECTED]> wrote:
> > I had write cache enabled on my main computer. Oops. I guess that
> > means we do need better documentation.
>
> Writeback cache on disk in iteself is not bad, it only gets
Hi!
> Along with this effort, could you let me know if the world actually
> cares about online fsck?
I'm not the world's spokeperson (yet ;-).
> Now we know how to do it I think, but is it
> worth the effort.
ext3's "lets fsck on every 20 mounts" is good idea, but it can be
annoying when
Hi!
Along with this effort, could you let me know if the world actually
cares about online fsck?
I'm not the world's spokeperson (yet ;-).
Now we know how to do it I think, but is it
worth the effort.
ext3's lets fsck on every 20 mounts is good idea, but it can be
annoying when
On Tue 2008-01-15 18:44:26, Daniel Phillips wrote:
On Jan 15, 2008 6:07 PM, Pavel Machek [EMAIL PROTECTED] wrote:
I had write cache enabled on my main computer. Oops. I guess that
means we do need better documentation.
Writeback cache on disk in iteself is not bad, it only gets bad if the
On Wed, 16 Jan 2008 12:51:44 +0100, Pavel Machek said:
I guess I should try to measure it. (Linux already does writeback
caching, with 2GB of memory. I wonder how important disks's 2MB of
cache can be).
It serves essentially the same purpose as the 'async' option in /etc/exports
(i.e. we
On Wed, Jan 16, 2008 at 08:43:25AM +1100, David Chinner wrote:
ext3 is not the only filesystem that will have trouble due to
volatile write caches. We see problems often enough with XFS
due to volatile write caches that it's in our FAQ:
In fact it will hit every filesystem. A write-back cache
The disk motor as a generator tale may not be purely folklore. When
an IDE drive is not in writeback mode, something special needs to done
to ensure the last write to media is not a scribble.
No it doesn't. The last write _is_ a scribble. Systems that make atomic
updates to disk drives use a
And I think there's a problem with drives that, upon sensing the
unreadable sector, assign an alternate even though the sector is fine, and
you eventually run out of spares.
You are assuming drives can't tell the difference between stray data loss
and sectors that can't be recovered by
On Jan 16, 2008 3:49 AM, Pavel Machek [EMAIL PROTECTED] wrote:
ext3's lets fsck on every 20 mounts is good idea, but it can be
annoying when developing. Having option to fsck while filesystem is
online takes that annoyance away.
I'm sure everyone on cc: knows this, but for the record you can
Alan Cox wrote:
Writeback cache on disk in iteself is not bad, it only gets bad if the
disk is not engineered to save all its dirty cache on power loss,
using the disk motor as a generator or alternatively a small battery.
It would be awfully nice to know which brands fail here, if any,
On Jan 16, 2008 2:06 PM, Bryan Henderson [EMAIL PROTECTED] wrote:
The disk motor as a generator tale may not be purely folklore. When
an IDE drive is not in writeback mode, something special needs to done
to ensure the last write to media is not a scribble.
No it doesn't. The last write
On Jan 15, 2008 22:05 -0500, Rik van Riel wrote:
With a filesystem that is compartmentalized and checksums metadata,
I believe that an online fsck is absolutely worth having.
Instead of the filesystem resorting to mounting the whole volume
read-only on certain errors, part of the filesystem
On Tue, 15 Jan 2008 20:44:38 -0500
"Daniel Phillips" <[EMAIL PROTECTED]> wrote:
> Along with this effort, could you let me know if the world actually
> cares about online fsck? Now we know how to do it I think, but is it
> worth the effort.
With a filesystem that is compartmentalized and
Hi Pavel,
Along with this effort, could you let me know if the world actually
cares about online fsck? Now we know how to do it I think, but is it
worth the effort.
Regards,
Daniel
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL
On Tue, 15 Jan 2008 20:24:27 -0500
"Daniel Phillips" <[EMAIL PROTECTED]> wrote:
> On Jan 15, 2008 7:15 PM, Alan Cox <[EMAIL PROTECTED]> wrote:
> > > Writeback cache on disk in iteself is not bad, it only gets bad
> > > if the disk is not engineered to save all its dirty cache on
> > > power loss,
On Jan 15, 2008 7:15 PM, Alan Cox <[EMAIL PROTECTED]> wrote:
> > Writeback cache on disk in iteself is not bad, it only gets bad if the
> > disk is not engineered to save all its dirty cache on power loss,
> > using the disk motor as a generator or alternatively a small battery.
> > It would be
> Writeback cache on disk in iteself is not bad, it only gets bad if the
> disk is not engineered to save all its dirty cache on power loss,
> using the disk motor as a generator or alternatively a small battery.
> It would be awfully nice to know which brands fail here, if any,
> because
On Jan 15, 2008 6:07 PM, Pavel Machek <[EMAIL PROTECTED]> wrote:
> I had write cache enabled on my main computer. Oops. I guess that
> means we do need better documentation.
Writeback cache on disk in iteself is not bad, it only gets bad if the
disk is not engineered to save all its dirty cache
Hi!
> > > > What are ext3 expectations of disk (is there doc somewhere)? For
> > > > example... if disk does not lie, but powerfail during write damages
> > > > the sector -- is ext3 still going to work properly?
> > >
> > > Nope. However the few disks that did this rapidly got firmware updates
On Tue, Jan 15, 2008 at 09:16:53PM +0100, Pavel Machek wrote:
> Hi!
>
> > > What are ext3 expectations of disk (is there doc somewhere)? For
> > > example... if disk does not lie, but powerfail during write damages
> > > the sector -- is ext3 still going to work properly?
> >
> > Nope. However
Hi!
> > What are ext3 expectations of disk (is there doc somewhere)? For
> > example... if disk does not lie, but powerfail during write damages
> > the sector -- is ext3 still going to work properly?
>
> Nope. However the few disks that did this rapidly got firmware updates
> because there are
Hi!
What are ext3 expectations of disk (is there doc somewhere)? For
example... if disk does not lie, but powerfail during write damages
the sector -- is ext3 still going to work properly?
Nope. However the few disks that did this rapidly got firmware updates
because there are other
On Tue, Jan 15, 2008 at 09:16:53PM +0100, Pavel Machek wrote:
Hi!
What are ext3 expectations of disk (is there doc somewhere)? For
example... if disk does not lie, but powerfail during write damages
the sector -- is ext3 still going to work properly?
Nope. However the few disks
Hi!
What are ext3 expectations of disk (is there doc somewhere)? For
example... if disk does not lie, but powerfail during write damages
the sector -- is ext3 still going to work properly?
Nope. However the few disks that did this rapidly got firmware updates
because there
On Jan 15, 2008 6:07 PM, Pavel Machek [EMAIL PROTECTED] wrote:
I had write cache enabled on my main computer. Oops. I guess that
means we do need better documentation.
Writeback cache on disk in iteself is not bad, it only gets bad if the
disk is not engineered to save all its dirty cache on
Writeback cache on disk in iteself is not bad, it only gets bad if the
disk is not engineered to save all its dirty cache on power loss,
using the disk motor as a generator or alternatively a small battery.
It would be awfully nice to know which brands fail here, if any,
because writeback
On Jan 15, 2008 7:15 PM, Alan Cox [EMAIL PROTECTED] wrote:
Writeback cache on disk in iteself is not bad, it only gets bad if the
disk is not engineered to save all its dirty cache on power loss,
using the disk motor as a generator or alternatively a small battery.
It would be awfully nice
On Tue, 15 Jan 2008 20:24:27 -0500
Daniel Phillips [EMAIL PROTECTED] wrote:
On Jan 15, 2008 7:15 PM, Alan Cox [EMAIL PROTECTED] wrote:
Writeback cache on disk in iteself is not bad, it only gets bad
if the disk is not engineered to save all its dirty cache on
power loss, using the disk
Hi Pavel,
Along with this effort, could you let me know if the world actually
cares about online fsck? Now we know how to do it I think, but is it
worth the effort.
Regards,
Daniel
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL
On Tue, 15 Jan 2008 20:44:38 -0500
Daniel Phillips [EMAIL PROTECTED] wrote:
Along with this effort, could you let me know if the world actually
cares about online fsck? Now we know how to do it I think, but is it
worth the effort.
With a filesystem that is compartmentalized and checksums
Pavel Machek wrote:
On Sat 2008-01-12 09:51:40, Theodore Tso wrote:
On Wed, Jan 09, 2008 at 02:52:14PM +0300, Al Boldi wrote:
Ok, but let's look at this a bit more opportunistic / optimistic.
Even after a black-out shutdown, the corruption is pretty minimal, using
ext3fs at least.
After a
Pavel Machek wrote:
On Sat 2008-01-12 09:51:40, Theodore Tso wrote:
On Wed, Jan 09, 2008 at 02:52:14PM +0300, Al Boldi wrote:
Ok, but let's look at this a bit more opportunistic / optimistic.
Even after a black-out shutdown, the corruption is pretty minimal, using
ext3fs at least.
After a
Hi Ted,
On Saturday 12 January 2008 06:51, Theodore Tso wrote:
> What is very hard to check is whether or not the link count on the
> inode is correct. Suppose the link count is 1, but there are
> actually two directory entries pointing at it. Now when someone
> unlinks the file through one of
> What are ext3 expectations of disk (is there doc somewhere)? For
> example... if disk does not lie, but powerfail during write damages
> the sector -- is ext3 still going to work properly?
Nope. However the few disks that did this rapidly got firmware updates
because there are other OS's that
On Sat 2008-01-12 09:51:40, Theodore Tso wrote:
> On Wed, Jan 09, 2008 at 02:52:14PM +0300, Al Boldi wrote:
> >
> > Ok, but let's look at this a bit more opportunistic / optimistic.
> >
> > Even after a black-out shutdown, the corruption is pretty minimal, using
> > ext3fs at least.
> >
>
>
Theodore Tso wrote:
> On Wed, Jan 09, 2008 at 02:52:14PM +0300, Al Boldi wrote:
> > Ok, but let's look at this a bit more opportunistic / optimistic.
> >
> > Even after a black-out shutdown, the corruption is pretty minimal, using
> > ext3fs at least.
>
> After a unclean shutdown, assuming you
Theodore Tso wrote:
On Wed, Jan 09, 2008 at 02:52:14PM +0300, Al Boldi wrote:
Ok, but let's look at this a bit more opportunistic / optimistic.
Even after a black-out shutdown, the corruption is pretty minimal, using
ext3fs at least.
After a unclean shutdown, assuming you have decent
On Sat 2008-01-12 09:51:40, Theodore Tso wrote:
On Wed, Jan 09, 2008 at 02:52:14PM +0300, Al Boldi wrote:
Ok, but let's look at this a bit more opportunistic / optimistic.
Even after a black-out shutdown, the corruption is pretty minimal, using
ext3fs at least.
After a unclean
What are ext3 expectations of disk (is there doc somewhere)? For
example... if disk does not lie, but powerfail during write damages
the sector -- is ext3 still going to work properly?
Nope. However the few disks that did this rapidly got firmware updates
because there are other OS's that
Hi Ted,
On Saturday 12 January 2008 06:51, Theodore Tso wrote:
What is very hard to check is whether or not the link count on the
inode is correct. Suppose the link count is 1, but there are
actually two directory entries pointing at it. Now when someone
unlinks the file through one of the
On Wednesday 09 January 2008 01:16, Andreas Dilger wrote:
> While an _incremental_ fsck isn't so easy for existing filesystem
> types, what is pretty easy to automate is making a read-only snapshot
> of a filesystem via LVM/DM and then running e2fsck against that. The
> kernel and filesystem have
On Wed, Jan 09, 2008 at 02:52:14PM +0300, Al Boldi wrote:
>
> Ok, but let's look at this a bit more opportunistic / optimistic.
>
> Even after a black-out shutdown, the corruption is pretty minimal, using
> ext3fs at least.
>
After a unclean shutdown, assuming you have decent hardware that
Bodo Eggert wrote:
> Al Boldi <[EMAIL PROTECTED]> wrote:
> > Even after a black-out shutdown, the corruption is pretty minimal, using
> > ext3fs at least. So let's take advantage of this fact and do an
> > optimistic fsck, to assure integrity per-dir, and assume no external
> > corruption. Then
Bodo Eggert wrote:
Al Boldi [EMAIL PROTECTED] wrote:
Even after a black-out shutdown, the corruption is pretty minimal, using
ext3fs at least. So let's take advantage of this fact and do an
optimistic fsck, to assure integrity per-dir, and assume no external
corruption. Then we release
Al Boldi <[EMAIL PROTECTED]> wrote:
> Even after a black-out shutdown, the corruption is pretty minimal, using
> ext3fs at least. So let's take advantage of this fact and do an optimistic
> fsck, to assure integrity per-dir, and assume no external corruption. Then
> we release this checked dir
Al Boldi [EMAIL PROTECTED] wrote:
Even after a black-out shutdown, the corruption is pretty minimal, using
ext3fs at least. So let's take advantage of this fact and do an optimistic
fsck, to assure integrity per-dir, and assume no external corruption. Then
we release this checked dir to the
Rik van Riel wrote:
> Al Boldi <[EMAIL PROTECTED]> wrote:
> > Ok, but let's look at this a bit more opportunistic / optimistic.
>
> You can't play fast and loose with data integrity.
Correct, but you have to be realistic...
> Besides, if we looked at things optimistically, we would conclude
>
Rik van Riel wrote:
Al Boldi [EMAIL PROTECTED] wrote:
Ok, but let's look at this a bit more opportunistic / optimistic.
You can't play fast and loose with data integrity.
Correct, but you have to be realistic...
Besides, if we looked at things optimistically, we would conclude
that no
On Wed, 9 Jan 2008 14:52:14 +0300
Al Boldi <[EMAIL PROTECTED]> wrote:
> Ok, but let's look at this a bit more opportunistic / optimistic.
You can't play fast and loose with data integrity.
Besides, if we looked at things optimistically, we would conclude
that no fsck will be needed, ever :)
>
Valerie Henson wrote:
> On Jan 8, 2008 8:40 PM, Al Boldi <[EMAIL PROTECTED]> wrote:
> > Rik van Riel wrote:
> > > Al Boldi <[EMAIL PROTECTED]> wrote:
> > > > Has there been some thought about an incremental fsck?
> > > >
> > > > You know, somehow fencing a sub-dir to do an online fsck?
> > >
> > >
Andi Kleen wrote:
>> Theodore Tso <[EMAIL PROTECTED]> writes:
>> > Now, there are good reasons for doing periodic checks every N mounts
>> > and after M months. And it has to do with PC class hardware. (Ted's
>> > aphorism: "PC class hardware is cr*p").
>>
>> If these reasons are good ones (some
On Wed, 09 Jan 2008 07:40:12 +0300, Al Boldi said:
> But why wouldn't it be possible to do this on the current fs infrastructure,
> using just a smart fsck, working incrementally on some sub-dir?
If you have /home/usera, /home/userb, and /home/userc, the vast majority of
fs screw-ups can't be
On Wed, 09 Jan 2008 07:40:12 +0300, Al Boldi said:
But why wouldn't it be possible to do this on the current fs infrastructure,
using just a smart fsck, working incrementally on some sub-dir?
If you have /home/usera, /home/userb, and /home/userc, the vast majority of
fs screw-ups can't be
Andi Kleen wrote:
Theodore Tso [EMAIL PROTECTED] writes:
Now, there are good reasons for doing periodic checks every N mounts
and after M months. And it has to do with PC class hardware. (Ted's
aphorism: PC class hardware is cr*p).
If these reasons are good ones (some skepticism here)
Valerie Henson wrote:
On Jan 8, 2008 8:40 PM, Al Boldi [EMAIL PROTECTED] wrote:
Rik van Riel wrote:
Al Boldi [EMAIL PROTECTED] wrote:
Has there been some thought about an incremental fsck?
You know, somehow fencing a sub-dir to do an online fsck?
Search for chunkfs
On Wed, 9 Jan 2008 14:52:14 +0300
Al Boldi [EMAIL PROTECTED] wrote:
Ok, but let's look at this a bit more opportunistic / optimistic.
You can't play fast and loose with data integrity.
Besides, if we looked at things optimistically, we would conclude
that no fsck will be needed, ever :)
On Jan 8, 2008 8:40 PM, Al Boldi <[EMAIL PROTECTED]> wrote:
> Rik van Riel wrote:
> > Al Boldi <[EMAIL PROTECTED]> wrote:
> > > Has there been some thought about an incremental fsck?
> > >
> > > You know, somehow fencing a sub-dir to do an online fsck?
> >
> > Search for "chunkfs"
>
> Sure, and
Rik van Riel wrote:
> Al Boldi <[EMAIL PROTECTED]> wrote:
> > Has there been some thought about an incremental fsck?
> >
> > You know, somehow fencing a sub-dir to do an online fsck?
>
> Search for "chunkfs"
Sure, and there is TileFS too.
But why wouldn't it be possible to do this on the current
> Andi Kleen wrote:
>> Theodore Tso <[EMAIL PROTECTED]> writes:
>> > Now, there are good reasons for doing periodic checks every N mounts
>> > and after M months. And it has to do with PC class hardware. (Ted's
>> > aphorism: "PC class hardware is cr*p").
>>
>> If these reasons are good ones
On Wed, 9 Jan 2008 00:22:55 +0300
Al Boldi <[EMAIL PROTECTED]> wrote:
> Has there been some thought about an incremental fsck?
>
> You know, somehow fencing a sub-dir to do an online fsck?
Search for "chunkfs"
--
All rights reversed.
--
To unsubscribe from this list: send the line
Andi Kleen wrote:
> Theodore Tso <[EMAIL PROTECTED]> writes:
> > Now, there are good reasons for doing periodic checks every N mounts
> > and after M months. And it has to do with PC class hardware. (Ted's
> > aphorism: "PC class hardware is cr*p").
>
> If these reasons are good ones (some
Andi Kleen wrote:
Theodore Tso [EMAIL PROTECTED] writes:
Now, there are good reasons for doing periodic checks every N mounts
and after M months. And it has to do with PC class hardware. (Ted's
aphorism: PC class hardware is cr*p).
If these reasons are good ones (some skepticism here)
1 - 100 of 104 matches
Mail list logo
