Re: regular fsck runs are too disturbing - and current approach does not work very well in detecting defects!
Jan Claeys wrote: The main reason (IMO) why defrag is not useful (anymore) is that for ages there hasn't been any (guaranteed) correlation between hardware order and software order of sectors on a disk. Defragmenting disks might actually fragment them more on a fysical level, and thus cause slow-downs. And in some cases (fysically) fragmented sectors might be faster to read/write than non-fragmented ones (I used a custom, partially self-written, diskette formatting program to do exactly that under MS-DOS!). So, any defrag program would require help from the hard disk's firmware to be really efficient (and AFAIK no firmware supports this). No, the only time the logical sectors become physically out of order are when defect remapping has taken place. Sequential reads of sectors in order are still the fastest way to access the disk, so access to files which are not fragmented is faster than files which are. -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: regular fsck runs are too disturbing - and current approach does not work very well in detecting defects!
Op maandag 08-10-2007 om 13:16 uur [tijdzone -0400], schreef Phillip
Susi:
Jan Claeys wrote:
But I think a similar API could be used to mark move bad sectors or
lost sectors, and that's more related to this discussion...
As I said, there is no need to make such an effort because ext rarely
becomes fragmented enough to worry about. The fact that the defrag
package has not really been maintained in 10 years shows that there is
no strong need for an offline defrag, let alone an online one.
The main reason (IMO) why defrag is not useful (anymore) is that for
ages there hasn't been any (guaranteed) correlation between hardware
order and software order of sectors on a disk. Defragmenting disks
might actually fragment them more on a fysical level, and thus cause
slow-downs. And in some cases (fysically) fragmented sectors might be
faster to read/write than non-fragmented ones (I used a custom,
partially self-written, diskette formatting program to do exactly that
under MS-DOS!). So, any defrag program would require help from the hard
disk's firmware to be really efficient (and AFAIK no firmware supports
this).
But, what I was thinking about was similar atomic operations that allow
_other_ filesystem cleaning tasks to be done while a filesystem is in
use (r/w). ('fsck' might be an example.)
I understand these don't exist now, but they might be a good idea for
future filesystems or filesystem versions... :)
--
Jan Claeys
--
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: regular fsck runs are too disturbing - and current approach does not work very well in detecting defects!
Op woensdag 03-10-2007 om 15:35 uur [tijdzone -0400], schreef Phillip Susi: Jan Claeys wrote: About doing live fsck defrag on a rw filesystem, IIRC Windows NT has a system API for doing e.g. atomic swap 2 sectors operations; does 'linux', or any of the filesystem drivers for it, support something like that? I think XFS or JFS supports online defragmenting, but no other work has been done in that area due to lack of need. Even the offline defrag package has not been maintained for the last 10 years due to lack of interest. When you don't have a silly problem with fragmentation, there is no motivation to solve the non problem. Ext2/ext3 suffer from fragmentation too, when available disk space gets low enough. But I think a similar API could be used to mark move bad sectors or lost sectors, and that's more related to this discussion... -- Jan Claeys -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: regular fsck runs are too disturbing - and current approach does not work very well in detecting defects!
Jan Claeys wrote: I'm not an Ubuntu developer, but if 'badblocks' looks for hardware defects, it's mostly useless on most hard disks in use these days. The HDD firmware does internal bad block detection replacement (using spare blocks on the disk reserved for that purpose). So if you can detect any bad blocks using a software check, it means that your hard disk is almost dead and should be replace ASAP (like, rather today than tomorrow). It can only remap the block on a write, not a read, but yea, smartmontools is a better method to monitor for defects. -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: regular fsck runs are too disturbing - and current approach does not work very well in detecting defects!
Op dinsdag 02-10-2007 om 13:56 uur [tijdzone -0400], schreef Phillip Susi: Jan Claeys wrote: I'm not an Ubuntu developer, but if 'badblocks' looks for hardware defects, it's mostly useless on most hard disks in use these days. The HDD firmware does internal bad block detection replacement (using spare blocks on the disk reserved for that purpose). So if you can detect any bad blocks using a software check, it means that your hard disk is almost dead and should be replace ASAP (like, rather today than tomorrow). It can only remap the block on a write, not a read, Which means it might be useful as an emergency solution while you're waiting for the new disks to arrive. but yea, smartmontools is a better method to monitor for defects. Indeed, 'smartmontools' for hardware-defects, fsck for filesystem-defects. About doing live fsck defrag on a rw filesystem, IIRC Windows NT has a system API for doing e.g. atomic swap 2 sectors operations; does 'linux', or any of the filesystem drivers for it, support something like that? -- Jan Claeys -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
