On Fri, Feb 23, 2007 at 05:37:23PM -0700, Andreas Dilger wrote:
> > Probably the only sane thing to do is to remember the bad sectors and
> > avoid attempting reading them; that would mean marking "automatic"
> > versus "explicitly requested" requests to determine whether or not to
> > filter th
Andreas Dilger wrote:
And clearing this list when the sector is overwritten, as it will almost
certainly be relocated at the disk level.
Certainly if the overwrite is successful.
-hpa
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to
On Feb 23, 2007 16:03 -0800, H. Peter Anvin wrote:
> Ric Wheeler wrote:
> > (1) read-ahead often means that we will retry every bad sector at
> >least twice from the file system level. The first time, the fs read
> >ahead request triggers a speculative read that includes the bad sector
> >(t
Ric Wheeler wrote:
We still have the following challenges:
(1) read-ahead often means that we will retry every bad sector at
least twice from the file system level. The first time, the fs read
ahead request triggers a speculative read that includes the bad sector
(triggering the error ha
On Fri, 2007-02-23 at 10:02 -0600, Steve French (smfltc) wrote:
> A field in i_size_write (i_size_seqcount) must be protected against
> simultaneous update otherwise we risk looping in i_size_read.
>
> The suggestion in fs.h is to use i_mutex which seems too dangerous due
> to the possibility of
A field in i_size_write (i_size_seqcount) must be protected against
simultaneous update otherwise we risk looping in i_size_read.
The suggestion in fs.h is to use i_mutex which seems too dangerous due
to the possibility of deadlock.
There are 65 places in the fs directory which lock an i_mute
To all who took an interest, and Neil Brown who gave help:
I've got the nfs server working now.
At the end there were several issues
(note that we're on dual-MIPS embedded system, starting off
with a very minimal system because of space constraints):
- /etc/services was not correct
- no network
In the IO/FS workshop, one idea we kicked around is the need to provide
better and more specific error messages between the IO stack and the
file system layer.
My group has been working to stabilize a relatively up to date libata +
MD based box, so I can try to lay out at least one "appliance
This makes in-core superblock fit into one cacheline here.
Before:
struct dentry *xattr_root; /* 124 4 */
/* --- cacheline 1 boundary (128 bytes) --- */
struct rw_semaphorexattr_dir_sem;/* 12812 */
intj_errno
