On Sat, 30 Jul 2005, Martin Jambor wrote:
> Hi and thanks for all answers.
>
> On 7/28/05, Andrew Morton <[EMAIL PROTECTED]> wrote:
> > > Is the error
> > > somehow signalled to anyone?
> >
> > Yes, it's propagated into the file's address_space for a later
> > fsync()/fdatasync()/msync() to detec
Hi and thanks for all answers.
On 7/28/05, Andrew Morton <[EMAIL PROTECTED]> wrote:
> > Is the error
> > somehow signalled to anyone?
>
> Yes, it's propagated into the file's address_space for a later
> fsync()/fdatasync()/msync() to detect.
I see, so a subsequent sync, fsync or umount fail with
>On Thu, 28 Jul 2005, Andrew Morton wrote:
>> Martin Jambor <[EMAIL PROTECTED]> wrote:
>> >
>> > Do filesystems try to relocate the data from bad blocks of the
>> > device?
>
>Only Windows NTFS, not others AFAIK (most filesytems can mark them during
>mkfs, that's all).
>
>> Nope. Disks will do tha
On Thu, 28 Jul 2005, Andrew Morton wrote:
> Martin Jambor <[EMAIL PROTECTED]> wrote:
> >
> > Do filesystems try to relocate the data from bad blocks of the
> > device?
Only Windows NTFS, not others AFAIK (most filesytems can mark them during
mkfs, that's all).
> Nope. Disks will do that interna
Martin Jambor <[EMAIL PROTECTED]> wrote:
>
> Hi,
>
> I have tried to find out how filesystems are supposed to handle the
> situation when an asynchronous writeout of a page fails and so had a
> look at the ext2 code. All I have found is that for example
> mpage_end_io_write sets the Error flag of
Hi,
I have tried to find out how filesystems are supposed to handle the
situation when an asynchronous writeout of a page fails and so had a
look at the ext2 code. All I have found is that for example
mpage_end_io_write sets the Error flag of both the page and its
mapping... and that is about it.
