[FUG-BR] Alguem ai usando ataraid de mais de 120G????
Eu tava tendo problemas sérios com um disco de 250G numa controladora promise, e acabei chegando a isto aqui, que me parece um bug. Só para ter certeza, alguém ai está usando ataraid (promise ou nao) com discos de mais de 120G? Não basta ser um array de mais de 120G, cada disco individual tem que ter mais de 120G. Se eu estiver certo, espero que corrijam antes do 5.4. Estou tendo problemas com isso desde o 5.2. João Carlos Mendes Luís wrote: I think I may have found the problem!!! Looking at the source code for arstrategy, we can find this: - static void arstrategy(struct bio *bp) { struct ar_softc *rdp = bp-bio_disk-d_drv1; int blkno, count, chunk, lba, lbs, tmplba; int drv = 0, change = 0; caddr_t data; - That is, lba is an int, 32 bits! Right below, this variable is used into a bio_pblkno, which is defined at sys/bio.h as (daddrt_t): - buf1-bp.bio_pblkno = lba; if ((buf1-drive = drv) 0) buf1-bp.bio_pblkno += rdp-offset; - But note that at the /sys/dev/ata/ata-all.h file, the ata_request.u.ata.lba is defined as (u_int64_t). Also, at sys/types.h, (daddr_t) is defined as (__int64_t). These are the data types used at ata-disk.c BTW: While searching for this bug, I found that a type (u_daddr_t) is defined at sys/blist.h as (u_int32_t). I did not care for it right now, but maybe this should be checked also. Hope I am wrong, but if not, this may be the bug I´ve been chasing since 5.2-R. To probe further: Should the ata-raid driver be allowed to write the disk at will? I did not even try to mount any partition, but it did overwrote my data. Maybe to update the raid information. I'm not sure, I did not search for this yet. João Carlos Mendes Luís wrote: Followup to my message with more news. It is not a problem with mount_ntfs. Indeed, it seems to be a problem with the ataraid code. Today I booted from 5.3RC4 install CD, and mounted NO partition on the problem disk. But this was enough to corrupt the partition again. How can I know if the ATA RAID code is LBA48 compatible? The chipset is a Promise 20378, which is supported, in theory. João Carlos Mendes Luís wrote: Hi all, I've just bought a Seagate 250G SATA drive to run in a shared desktop at home. It should have 3 boot partitions: 16M FreeBSD 5, 16M linux, 32M NTFS for Windows XP. The remaining wil be formatted with FAT32 to be used as a common data for the 3 operating systems. Well, everything seemed to be fine. I copied the FreeBSD partition from the previous installed disk with dump(8), and installed XP from CDs. But suddenly, the data and NTFS partitions began to disappear. I don't know exactly what were the steps used to crash the disk, but it happened at least 3 times, after 3 full windows installs (which are not quick, for my sadness). In the last one I could almost detect it. I finished the initial windows instalation, and booted into FreeBSD to make sure the NTFS and FAT partitions were available. They seemed to be. Then I reboot into windows, and it crashed, with a missing HAL.DLL. Boot again into FreeBSD, and the NTFS partition still seemed ok. But I gone into the \WINDOWS\system32, and did an ls. The kernel pushed some errors with bad magic or something like that, and the file system locked. Also, the boot information for the first FAT32 partition has been completely destroyed, leaving it unreadable. The mainboard is an ASUS K8V, with 1G RAM. I'm running the 32 bit version of FreeBSD, although it is an AMD64 machine. The 250G SATA disk is on the promise RAID, and I have another PATA 120G on the promise RAID, and a 40G PATA on standard IDE. I already had a problem with a previous ASUS board in which the promise raid could not deal with disks bigger than 120G. The symptons were very similar. Could this be the problem? Does somebody know if FreeBSD or mount_ntfs has any kind of disk size limitation in this hardware? Oh, I did remember now that I was using mount_ntfs -o noatime, if that matters. Thanks for any help, Jonny PS: Now it has been fully reformatted with no NTFS, using FAT32 instead. But I'm afraid of getting into FreeBSD again in this machine. Please help! :-( ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED] From - Mon ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED] === Este mail so pode ser lido em sistemas operacionais da Microsoft mediante o pagamento de EU45.99/msg a
Re: [FUG-BR] Alguem ai usando ataraid de mais de 120G????
João Carlos Mendes Luís wrote: Eu tava tendo problemas sérios com um disco de 250G numa controladora promise, e acabei chegando a isto aqui, que me parece um bug. Só para ter certeza, alguém ai está usando ataraid (promise ou nao) com discos de mais de 120G? Não basta ser um array de mais de 120G, cada disco individual tem que ter mais de 120G. Se eu estiver certo, espero que corrijam antes do 5.4. Estou tendo problemas com isso desde o 5.2. Fala Jonny, boa noite. Nos temos alguns ambientes em producao sem problemas, com ataraid. Na verdade quando tivemos historico de problemas (foram bem poucos, e todos com solucao felizmente) em alguns clientes foi mais no suporte SATA do que com a controladora RAID. Vou te colar os dados de um servidor com RAID1, Controladora Promise PDC20378 com discos SATA de 160G. (eksffa:/dev/ttyp0)~# pciconf -lv | grep -B 2 RAID [EMAIL PROTECTED]:4:0: class=0x010400 card=0x80f51043 chip=0x3373105a rev=0x02 hdr=0x00 vendor = 'Promise Technology Inc' device = 'PDC20378? FastTrak RAID Controller' class= mass storage subclass = RAID (eksffa:/dev/ttyp0)~# grep Promise /var/run/dmesg.boot atapci0: Promise PDC20378 SATA150 controller port 0xd800-0xd87f,0xdfa0-0xdfaf,0xdf00-0xdf3f mem 0xfea8-0xfea9,0xfeaae000-0xfeaaefff irq 23 at device 4.0 on pci2 (eksffa:/dev/ttyp0)~# atacontrol info 2 Master: ad4 Maxtor 6Y160M0/YAR51BW0 Slave: no device present (eksffa:/dev/ttyp0)~# atacontrol info 3 Master: ad6 Maxtor 6Y160M0/YAR51BW0 Slave: no device present (eksffa:/dev/ttyp0)~# grep -i raid /var/run/dmesg.boot ar0: 156334MB ATA RAID1 array [19929/255/63] status: READY subdisks: ar0: 156334MB ATA RAID1 array [19929/255/63] status: READY subdisks: ar0: 156334MB ATA RAID1 array [19929/255/63] status: READY subdisks: (eksffa:/dev/ttyp0)~# atacontrol status ar0 ar0: ATA RAID1 subdisks: ad6 ad4 status: READY João Carlos Mendes Luís wrote: I think I may have found the problem!!! Looking at the source code for arstrategy, we can find this: - static void arstrategy(struct bio *bp) { struct ar_softc *rdp = bp-bio_disk-d_drv1; int blkno, count, chunk, lba, lbs, tmplba; int drv = 0, change = 0; caddr_t data; - That is, lba is an int, 32 bits! Right below, this variable is used into a bio_pblkno, which is defined at sys/bio.h as (daddrt_t): - buf1-bp.bio_pblkno = lba; if ((buf1-drive = drv) 0) buf1-bp.bio_pblkno += rdp-offset; - But note that at the /sys/dev/ata/ata-all.h file, the ata_request.u.ata.lba is defined as (u_int64_t). Also, at sys/types.h, (daddr_t) is defined as (__int64_t). These are the data types used at ata-disk.c BTW: While searching for this bug, I found that a type (u_daddr_t) is defined at sys/blist.h as (u_int32_t). I did not care for it right now, but maybe this should be checked also. Hope I am wrong, but if not, this may be the bug I´ve been chasing since 5.2-R. To probe further: Should the ata-raid driver be allowed to write the disk at will? I did not even try to mount any partition, but it did overwrote my data. Maybe to update the raid information. I'm not sure, I did not search for this yet. João Carlos Mendes Luís wrote: Followup to my message with more news. It is not a problem with mount_ntfs. Indeed, it seems to be a problem with the ataraid code. Today I booted from 5.3RC4 install CD, and mounted NO partition on the problem disk. But this was enough to corrupt the partition again. How can I know if the ATA RAID code is LBA48 compatible? The chipset is a Promise 20378, which is supported, in theory. João Carlos Mendes Luís wrote: Hi all, I've just bought a Seagate 250G SATA drive to run in a shared desktop at home. It should have 3 boot partitions: 16M FreeBSD 5, 16M linux, 32M NTFS for Windows XP. The remaining wil be formatted with FAT32 to be used as a common data for the 3 operating systems. Well, everything seemed to be fine. I copied the FreeBSD partition from the previous installed disk with dump(8), and installed XP from CDs. But suddenly, the data and NTFS partitions began to disappear. I don't know exactly what were the steps used to crash the disk, but it happened at least 3 times, after 3 full windows installs (which are not quick, for my sadness). In the last one I could almost detect it. I finished the initial windows instalation, and booted into FreeBSD to make sure the NTFS and FAT partitions were available. They seemed to be. Then I reboot into windows, and it crashed, with a missing HAL.DLL. Boot again into FreeBSD, and the NTFS partition still seemed ok. But I gone into the \WINDOWS\system32, and did an ls. The kernel pushed some errors with bad magic or something like that, and the file system locked. Also, the boot information for the first FAT32 partition has been completely destroyed, leaving it unreadable. The