I have linux 2.4.20 + XFS from CVS 09-Jan-2003. System is based on RedHat 8.0. Motherboard ASUS A7V266A (via KT266A chipset) 512MB RAM 2 IBM SCSI disks connected to Adaptec 2940U2W CD-RW, DVD-RAM co
Olaf, Do you have dma enabled on your IDE disks? I can't think of any reason off the top of my head why a cat from hda -> hdc should be affected by XFS, as you aren't using the filesystem for that -
I recommend backing up before using hdparm. I've actually had hard locks from playing with dma this way. Filesystem corruptions are not unknown when changing settings with hdparm. This is largely due
Yes, I know. I just don't know if XFS code changes some buffering etc. Maybe with vanilla kernel it would be the same. I just have no easy way to test it. Make sure dma is enabled on hda and hdc and
I have linux 2.4.20 + XFS from CVS 09-Jan-2003. System is based on RedHat 8.0. Motherboard ASUS A7V266A (via KT266A chipset) 512MB RAM 2 IBM SCSI disks connected to Adaptec 2940U2W CD-RW, DVD-RAM con
OK, I'll try to repartition my disks to get some free space to install a vanilla kernel. BTW, do you think that preemptible or low-latency would help here? If yes, can these patches be safely merged
Why it should be better? Doing 'cat' I have perfect copy of disk. You think that I will get lower latency with your scenario? And all my ACLs go to hell :) BTW try to do it with NTFS partition :( The
Come on, its not that bad. I use dd to copy disks like the above fairly often. Mind you, I do it in single-user mode so the partitions are all mounted read-only. And of course I never try to mount t
Seth is suggesting copying the contents of the filesystem, not the complete device. What you really need is xfs_copy implemented on linux I think, failing that xfs_dump piped into xfs_restore which w
XFS should not affect this in any way, I am sure the unmodified kernel would behave the same way for you. Steve -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lor
You can try to enable DMA for your IDE harddrives. hdparm -d1 /dev/hda hdparm -d1 /dev/hdc Enable VIA82CXXX chipset support in your kernel as well. Paul Attachment: smime.p7s Description: S/MIME Cry
Hi, I just repartitioned my SCSI disks and got 2GB free. I installed RH 9 with Gnome. It took only about 1.6GB :) So: With RedHat 2.4.20-8 kernel it is much better. But it still has some freezes. Loa
what happens if you use bs=4096 to dd ? doing a strace of cat shows it appears to do read/writes in 4096 byte blocks perhaps this is making a difference. -- Ethan Benson http://www.alaska.net/~erbens
I have tried 512,1024,2048,4096,8192,16384. It works smoothly with all above values. The only difference was with 512: the speed was cut about half. dd if=/dev/zero of=/dev/hda1 bs=1 count=100000000
no not really, all bash is doing is setting stdout to the file you specify for the redirect before it execs cat. looking at strace tests i don't really see any real difference between what dd is doin
I have linux 2.4.20 + XFS from CVS 09-Jan-2003. System is based on RedHat 8.0. Motherboard ASUS A7V266A (via KT266A chipset) 512MB RAM 2 IBM SCSI disks connected to Adaptec 2940U2W CD-RW, DVD-RAM co
Olaf, Do you have dma enabled on your IDE disks? I can't think of any reason off the top of my head why a cat from hda -> hdc should be affected by XFS, as you aren't using the filesystem for that -
I recommend backing up before using hdparm. I've actually had hard locks from playing with dma this way. Filesystem corruptions are not unknown when changing settings with hdparm. This is largely due
Yes, I know. I just don't know if XFS code changes some buffering etc. Maybe with vanilla kernel it would be the same. I just have no easy way to test it. Make sure dma is enabled on hda and hdc and