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 both the page and its > mapping... and that is about it.
yup. > What happens to these pages later on? They get reclaimed without being written. > Does the memory manager attempt to write them again? No. Because if the error persists the machine will run out of memory in a fatal manner. > 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. > Do filesystems try to relocate the data > from bad blocks of the device? Nope. Disks will do that internally. If a disk gets a write I/O error it's generally dead. Nowadays I/O errors generally arise from storage networks when something in the network is disrupted. Possibly our behaviour is wrong in that case, although it could be argued that the retry logic should be implemented at the storage layer and not the VFS layer. The out-of-memory problem is a killer. - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
