On Mon, Feb 26, 2007 at 04:33:37PM +1100, Neil Brown wrote:
Do we want a path in the other direction to handle write errors? The
file system could say Don't worry to much if this block cannot be
written, just return an error and I will write it somewhere else?
This might allow md not to fail
the new location. I believe this should be always true, so presumably
with all modern disk drives a write error should mean something very
serious has happend.
Not quite that simple.
If you write a block aligned size the same size as the physical media
block size maybe this is true. If you
On Mon, 2007-02-26 at 08:25 -0500, Theodore Tso wrote:
Somewhat off-topic, but my one big regret with how the dm vs. evms
competition settled out was that evms had the ability to perform block
device snapshots using a non-LVM volume as the base --- and that EVMS
allowed a single drive to be
Alan wrote:
the new location. I believe this should be always true, so presumably
with all modern disk drives a write error should mean something very
serious has happend.
Not quite that simple.
I think that write errors are normally quite serious, but there are exceptions
which might
On Sat, Feb 03, 2007 at 12:30:55AM -0500, J. Bruce Fields wrote:
This is another attempt at a posix locking interface that allows us to
provide NFS clients with cluster-coherent locking without blocking lockd
while the filesystem goes off and talks to other nodes.
Marc and I have an updated
I'm not sure. Turning, for example, the statat(dir_fd, name == NULL)
error case into fstat(dir_fd) sounds like a way for apps, admittedly
buggy ones, to be surprised. Maybe libc would be exptected to catch
the error before performing the shared system call?
At that point would it not
Alan wrote:
I'm not sure. Turning, for example, the statat(dir_fd, name == NULL)
error case into fstat(dir_fd) sounds like a way for apps, admittedly
buggy ones, to be surprised. Maybe libc would be exptected to catch
the error before performing the shared system call?
At that point
On Feb 26, 2007, at 13:46:21, H. Peter Anvin wrote:
Alan wrote:
I'm not sure. Turning, for example, the statat(dir_fd, name ==
NULL) error case into fstat(dir_fd) sounds like a way for apps,
admittedly buggy ones, to be surprised. Maybe libc would be
exptected to catch the error
Theodore Tso wrote:
In any case, the reason why I bring this up is that it would be really
nice if there was a way with a single laptop drive to be able to do
snapshots and background fsck's without having to use initrd's with
device mapper.
This is a major part of why I've been trying to
Theodore Tso wrote:
Can someone with knowledge of current disk drive behavior confirm that
for all drives that support bad block sparing, if an attempt to write
to a particular spot on disk results in an error due to bad media at
that spot, the disk drive will automatically rewrite the sector to
Jeff Garzik wrote:
Theodore Tso wrote:
Can someone with knowledge of current disk drive behavior confirm that
for all drives that support bad block sparing, if an attempt to write
to a particular spot on disk results in an error due to bad media at
that spot, the disk drive will automatically
One interesting counter example is a smaller write than a full page - say 512
bytes out of 4k.
If we need to do a read-modify-write and it just so happens that 1 of the 7
sectors we need to read is flaky, will this look like a write failure?
The current core kernel code can't handle
On Monday, February 26, 2007 9:42 AM, Ric Wheeler wrote:
Which brings us back to a recent discussion at the file
system workshop on being
more repair oriented in file system design so we can survive
situations like
this a bit more reliably ;-)
On the second day of the workshop, there
13 matches
Mail list logo
