Re: How can I use BD-RE with UFS on geli?
From: SAITOU Toshihide to...@ruby.ocn.ne.jp Subject: Re: How can I use BD-RE with UFS on geli? Date: Wed, 15 Apr 2009 19:45:48 +0900 (JST) In message: 20090412.134212.26081.to...@ruby.ocn.ne.jp SAITOU Toshihide to...@ruby.ocn.ne.jp writes: I tried BD-RE with UFS on geli but didn't success. What was wrong the below? P.S. BD-RE with UFS is the same result (not usable). 1. format the disk dvd+rw-format is failed but after this step the disk is newfs-able. # diskinfo -v /dev/acd0 /dev/acd0 2048# sectorsize 8796093020160 # mediasize in bytes (8.0T) 4294967295 # mediasize in sectors # kldload atapicam # dvd+rw-format /dev/cd0 # kldunload atapicam # diskinfo -v /dev/acd0 /dev/acd0 2048# sectorsize 24220008448 # mediasize in bytes (23G) 11826176# mediasize in sectors 2. newfs # newfs /dev/acd0 the following message was detected: kernel: acd0: FAILURE - READ_BIG MEDIUM ERROR asc=0x11 ascq=0x05 3. glabel and mount but the disk access frequently failed with these messages (offset and length is not always the same): kernel: acd0: FAILURE - READ_BIG MEDIUM ERROR asc=0x11 ascq=0x05 kernel: g_vfs_done():label/DailyBackup[READ(offset=2697789440, length=16384)]error = 5 Since I wrote this message and did something, I rarely see the READ_BIG MEDIUM ERROR error for now, almost ok, thanks. This is something I did JFYI: * firmware update * gnome and related ports update (include devel/fam to devel/gamin change) * sector size change # dd if=/dev/zero bs=2048 count=1 of=/dev/acd0 (new media emits READ_BIG MEDIUM ERROR, maybe inevitable(?)) # geli init -s 4096 /dev/acd0 # geli attach acd0 # dd if=/dev/zero bs=4194304 count=256 of=/dev/acd0.eli 256+0 records in 256+0 records out 1073741824 bytes transferred in 347.738376 secs (3087786 bytes/sec) # newfs -b 65536 -S 4096 /dev/acd0.eli # glabel label -v DailyBackup /dev/acd0.eli # mount /dev/label/DailyBackup /od # tar cf - foo | gzip -9 | dd bs=65536 if=/dev/stdin of=/od/foo.tgz 18697+2 records in 18697+2 records out 1225348564 bytes transferred in 733.809511 secs (1669846 bytes/sec) The theoretical transfer speed is 4.5MB/s (288 Mbps) so this is slow even I use the x2 BD-RE media and drive but I don't know which part is saturated. Thanks, SAITOU Toshihide ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Vim port problem
In message: 1bd550a00904190201q38e947eeq3b152a0a75782...@mail.gmail.com Fernando Apesteguía fernando.apesteg...@gmail.com writes: 2009/4/19 Glen Barber glen.j.bar...@gmail.com: 2009/4/19 Fernando Apesteguía fernando.apesteg...@gmail.com: Hi all, I have the latest version of the ports collection (gotten with portsnap). I performed a whole update of my system (FreeBSD 7.1-RELEASE-p4 #12). Everything went fine save the vim port. An upgrade of the base system Should Not(Tm) affect installed ports under normal conditions. It is unable to download vim-7.2.tar.bz2 despite the fact that the URL portupgrade tries to download from, exists: http://ftp.vim.org/pub/vim/unix/vim-7.2.tar.bz2 It was unable to download the file from any other sites. Several different errors (Move permanently, range request not satisfiable...) I am unfamiliar with automated port utilities. What happens if you do the following?: cd /usr/ports/editors/vim; make deinstall distclean; make install clean It fetches all the files from the remote site without problems and it installs it. However, I downloaded that file from the first site using 'fetch', place the file in /usr/ports/distfiles/vim and I could install the package... Don't confuse ports and packages. They are two different ways to install third-party software (until they are installed -- then everything is a package). Sorry, change package for port. What I wanted to say is: when installing the port, it couldn't download one of the needed files (vim-7.2.tar.bz2). After I did it by hand, it could install the port (compiling and all the stuff) because portupgrade found the file already downloaded in /usr/ports/distfiles/vim. http://www.mail-archive.com/freebsd-users...@jp.freebsd.org/msg03072.html According to the link, the ports system fetch the file with -r (resume) option when the previous file transfer had interrupted. However the file entity is changed with the same file name in that period causes the fetch program failed, so you needed the cleaning out of the file or fetch by hand before upgrade, I guess. I hope the ports system can handle this situation. SAITOU Toshihide ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: How can I use BD-RE with UFS on geli?
In message: 20090412.134212.26081.to...@ruby.ocn.ne.jp SAITOU Toshihide to...@ruby.ocn.ne.jp writes: I tried BD-RE with UFS on geli but didn't success. What was wrong the below? P.S. BD-RE with UFS is the same result (not usable). 1. format the disk dvd+rw-format is failed but after this step the disk is newfs-able. # diskinfo -v /dev/acd0 /dev/acd0 2048# sectorsize 8796093020160 # mediasize in bytes (8.0T) 4294967295 # mediasize in sectors # kldload atapicam # dvd+rw-format /dev/cd0 # kldunload atapicam # diskinfo -v /dev/acd0 /dev/acd0 2048# sectorsize 24220008448 # mediasize in bytes (23G) 11826176# mediasize in sectors 2. newfs # newfs /dev/acd0 the following message was detected: kernel: acd0: FAILURE - READ_BIG MEDIUM ERROR asc=0x11 ascq=0x05 3. glabel and mount but the disk access frequently failed with these messages (offset and length is not always the same): kernel: acd0: FAILURE - READ_BIG MEDIUM ERROR asc=0x11 ascq=0x05 kernel: g_vfs_done():label/DailyBackup[READ(offset=2697789440, length=16384)]error = 5 SAITOU Toshihide ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
How can I use BD-RE with UFS on geli?
I tried BD-RE with UFS on geli but didn't success. What was wrong the below? * BDR-S03J, Pioneer SATAT BD/DVD/CD Writer * FreeBSD 7-STABLE (Apr. 5) 1. when insert BD-RE: [/var/log/messages] acd0: FAILURE - READ_TOC ILLEGAL REQUEST asc=0x24 ascq=0x00 (cd0:ata6:0:0:0): READ TOC/PMA/ATIP. CDB: 43 0 0 0 0 0 0 0 4 0 (cd0:ata6:0:0:0): CAM Status: SCSI Status Error (cd0:ata6:0:0:0): SCSI Status: Check Condition (cd0:ata6:0:0:0): ILLEGAL REQUEST asc:24,0 (cd0:ata6:0:0:0): Invalid field in CDB (cd0:ata6:0:0:0): Unretryable error 2. maybe the diskinfo is wrong. (READ_TOC ILLEGAL REQUEST is related?) # diskinfo -v /dev/acd0 /dev/acd0 2048# sectorsize 8796093020160 # mediasize in bytes (8.0T) 4294967295 # mediasize in sectors 3. trying disk format with dvd+rw-format was failed. # dvd+rw-format /dev/cd0 * BD/DVD±RW/-RAM format utility by ap...@fy.chalmers.se, version 7.1. * 25.0GB BD media detected. * formatting 63.9% # [/var/log/messages] acd0: FAILURE - READ_TOC ILLEGAL REQUEST asc=0x24 ascq=0x00 acd0: FAILURE - READ_TOC ILLEGAL REQUEST asc=0x24 ascq=0x00 (cd0:ata6:0:0:0): READ TOC/PMA/ATIP. CDB: 43 2 0 0 0 0 aa 0 c 0 (cd0:ata6:0:0:0): CAM Status: SCSI Status Error (cd0:ata6:0:0:0): SCSI Status: Check Condition (cd0:ata6:0:0:0): ILLEGAL REQUEST asc:24,0 (cd0:ata6:0:0:0): Invalid field in CDB (cd0:ata6:0:0:0): Unretryable error 4. but after the above, the diskinfo is something sane: # diskinfo -v /dev/acd0 /dev/acd0 2048# sectorsize 24220008448 # mediasize in bytes (23G) 11826176# mediasize in sectors 5. so I tried geli init # geli init /dev/acd0 # geli attach /dev/acd0 GEOM_ELI: Device acd0.eli created. GEOM_ELI: Encryption: AES-CBC 128 GEOM_ELI: Crypto: software 6. then newfs: # newfs /dev/acd0.eli /dev/acd0.eli: 23098.0MB (47304700 sectors) block size 16384, fragment size 2048 using 126 cylinder groups of 183.77MB, 11761 blks, 23552 inodes. super-block backups (for fsck -b #) at: 160, 376512, 752864, 1129216, 1505568, 1881920, 2258272, 2634624, 3010976, 3387328, 3763680, 4140032, 4516384, 4892736, 5269088, 5645440, 6021792, 6398144, 6774496, 7150848, 7527200, 7903552, 8279904, 8656256, 9032608, 9408960, 9785312, 10161664, 10538016, 10914368, 11290720, 11667072, 12043424, 12419776, 12796128, 13172480, 13548832, 13925184, 14301536, 14677888, 15054240, 15430592, 15806944, 16183296, 16559648, 16936000, 17312352, 17688704, 18065056, 18441408, 18817760, 19194112, 19570464, 19946816, 20323168, 20699520, 21075872, 21452224, 21828576, 22204928, 22581280, 22957632, 2984, 23710336, 24086688, 24463040, 24839392, 25215744, 25592096, 25968448, 26344800, 26721152, 27097504, 27473856, 27850208, 28226560, 28602912, 28979264, 29355616, 29731968, 30108320, 30484672, 30861024, 31237376, 31613728, 31990080, 32366432, 32742784, 33119136, 33495488, 33871840, 34248192, 34624544, 35000896, 35377248, 35753600, 36129952, 36506304, 36882656, 37259008, 37635360, 38011712, 38388064, 38764416, 39140768, 39517120, 39893472, 40269824, 40646176, 41022528, 41398880, 41775232, 42151584, 42527936, 42904288, 43280640, 43656992, 44033344, 44409696, 44786048, 45162400, 45538752, 45915104, 46291456, 46667808, 47044160 [/var/log/messages] acd0: FAILURE - READ_BIG MEDIUM ERROR asc=0x11 ascq=0x05 GEOM_ELI: g_eli_read_done() failed acd0.eli[READ(offset=65536, length=2048)] * this was not always seen and the offset or the lenth is random during my trial. After this I can mount /dev/acd0.eli but the programs which access to this disk frequently abort with these log messages: acd0: FAILURE - READ_BIG MEDIUM ERROR asc=0x11 ascq=0x05 GEOM_ELI: g_eli_read_done() failed acd0.eli[READ(offset=11946934272, length=2048)] g_vfs_done():label/DailyBackup[READ(offset=11946934272, length=2048)]error = 5 acd0: FAILURE - READ_BIG MEDIUM ERROR asc=0x11 ascq=0x05 GEOM_ELI: g_eli_read_done() failed acd0.eli[READ(offset=2697789440, length=16384)] g_vfs_done():label/DailyBackup[READ(offset=2697789440, length=16384)]error = 5 acd0: FAILURE - READ_BIG MEDIUM ERROR asc=0x11 ascq=0x05 GEOM_ELI: g_eli_read_done() failed acd0.eli[READ(offset=11946934272, length=2048)] g_vfs_done():label/DailyBackup[READ(offset=11946934272, length=2048)]error = 5 I feel the disk access sometimes goes over the disk area because of the incorrect disk parameters. Thank you. --- SAITOU Toshihide ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
