Eu tava tendo problemas srios com um disco de 250G numa controladora
promise, e acabei chegando a isto aqui, que me parece um bug.  S para
ter certeza, algum ai est usando ataraid (promise ou nao) com discos
de mais de 120G?  No 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.

Joo Carlos Mendes Lus 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 Ive 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.
> 
> 
> 
> Joo Carlos Mendes Lus 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.
>>
>>Joo Carlos Mendes Lus 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 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@fug.com.br
http://mail.fug.com.br/mailman/listinfo/freebsd_fug.com.br

Responder a