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: 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 Slave: no device present
(eksffa:/dev/ttyp0)~# atacontrol info 3
Master: ad6 Slave: no device present
(eksffa:/dev/ttyp0)~# grep -i raid /var/run/dmesg.boot
ar0: 156334MB [19929/255/63] status: READY subdisks:
ar0: 156334MB [19929/255/63] status: READY subdisks:
ar0: 156334MB [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 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
, (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 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 pro
