[FUG-BR] Alguem ai usando ataraid de mais de 120G????
Patrick Tracanelli
eksffa em freebsdbrasil.com.br
Qui Abr 28 18:57:07 BRT 2005
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
atapci0 em pci2: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
0xfea80000-0xfea9ffff,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 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 em freebsd.org mailing list
>>>>http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
>>>>To unsubscribe, send any mail to "freebsd-hackers-unsubscribe em freebsd.org"
>>>
>>>>From - Mon
>>>
>>>_______________________________________________
>>>freebsd-hackers em freebsd.org mailing list
>>>http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
>>>To unsubscribe, send any mail to "freebsd-hackers-unsubscribe em freebsd.org"
>>
>>===============================================================================
>>Este mail so pode ser lido em sistemas operacionais da Microsoft mediante
>>o pagamento de EU45.99/msg a Open-AMS Foundation. Leia a Open-AMSF License.
>>Lista Nacao-l (C) 2001-2005 by the Regents of the Open Ai Meu Saco Foundation,
>>Qualquer mensagem ou texto incluindo esta mensagem deve obrigatoriamente
>>seguir a Open-AMSF License, pela definicao de OpenSourceEmail.
>>All Rights Reserved. Qualquer duvida: consulte o FAA desta lista.
>>===============================================================================
>>Este mail esta em Contexto AiMeuSaco(TM) - (C)1994-2005 Open-AMSF
>>O Conteudo dele NAO e' veridico. Qualquer semelhanca com fatos,
>>eventos ou personagens e' mera coincidencia.
>>===============================================================================
>>AMS, 11 anos trabalhando na democratizacao do ruido.
>>===============================================================================
>
>
> _______________________________________________
> Freebsd mailing list
> Freebsd em fug.com.br
> http://mail.fug.com.br/mailman/listinfo/freebsd_fug.com.br
--
Atenciosamente,
Patrick Tracanelli
FreeBSD Brasil LTDA.
The FreeBSD pt_BR Documentation Project
http://www.freebsdbrasil.com.br
patrick @ freebsdbrasil.com.br
"Long live Hanin Elias, Kim Deal!"
_______________________________________________
Freebsd mailing list
Freebsd em fug.com.br
http://mail.fug.com.br/mailman/listinfo/freebsd_fug.com.br
Mais detalhes sobre a lista de discussão freebsd