Re: Performance!
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Kris Kennaway wrote: Krassimir Slavchev wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello, Kris Kennaway wrote: Krassimir Slavchev wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello, Here are lock profiling results with select patch applied. OK, you are doing I/O over TCP. Are you sure you are using TCP on both systems? Linux may not be defaulting to TCP transport for local queries. Add --pgsql-host= to your sysbench command line to make it communicate over a local domain socket, which is much more efficient. Kris Hmm, Yes linux uses local domain sockets! Here are results using local domain sockets on FreeBSD too: #threads#tranzactions/sec 1 728 5 2996 10 5301 20 3931 40 2466 60 1852 80 1424 100 1216 Just to remember: Linux (2.6.18) #threads#transactions/sec 1 693 5 3539 10 5789 20 5791 40 5661 60 5517 80 5401 100 5319 I have results using Fedora 8 on the same hardware: Linux (2.6.23) #threads#transactions/sec 1 740 5 2675 10 6486 20 6893 40 6623 60 6623 80 6522 100 6417 If we look at the results with up to 10 threads the performance of FreeBSD is very good. May be something can be tuned for number of threads number of CPUs? Are you interested in lock profiling statistics with more threads than the number of CPUs? Yes, it's still performing anomalously. Glad we're making progress though :) Kris Okay, but how many threads will be more useful to test with? Best Regards -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFHhdMIxJBWvpalMpkRAowhAKCOLh6eUptQhVQlUA2O2vSS4fi6XACaA8Bx BVgsYLIpqdKZpMdaz4mj9gg= =MhN8 -END PGP SIGNATURE- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Cannot mount a nfs share after doing a snapshot
El jueves 10 de enero a las 01:10:17 CET, Julian H. Stacey escribió: Julian H. Stacey wrote: I too saw mountd / exports just fail on 2 systems upgraded in last days from 7RC4 to newest 7 Stable (CTM src-7 80, received here Jan 6 15:15 CEST=GMT+01:00). I am not using .snap snapshot. My other AMD NFS on other FreeBSD-4 6 hosts remains OK. AMD NFS as client server was working till then. I just upgraded src/ rebooted exports failed. messages: mountd[563]: can't change attributes for / mountd[563]: bad exports list line / host1 host2 host3 named seems to resolve hosts OK though. (my usual first suspect :-) su; mount_nfs lapd:/usr /mnt [udp] lapd:/usr: Permission denied Maybe changed hosts/pam/ssh/inetd type root auth defaults between RC4 now ? My mistake. Fixed here by running mergemaster -sicvP removing ::1 from my /etc/hosts to avoid IPV6. Yes, you are right, I have following your suggestions and the problem has gone away. Take a look at the following lines in /usr/share/examples/etc/hosts: ::1 localhost localhost.my.domain 127.0.0.1 localhost localhost.my.domain I have changed both lines to point out my own domain: ::1 localhost localhost.sanabria.es 127.0.0.1 localhost localhost.sanabria.es Before this change, I had: ::1 localhost localhost.localdomain 127.0.0.1 localhost localhost.localdomain Thus, it was my fault, as I did not make the mergemaster in the right way. Greg, that works for you? Thanks a lot Julian for your reply. pgpzBhpFt9oVL.pgp Description: PGP signature
Rancid/Expect failing on FreeBSD/SMP systems
My apologies for posting this both to the Rancid list and FreeBSD-STABLE, however I am not sure where to start troubleshooting this issue - I am suspecting it is a FreeBSD issue, but I am thinking we are probably not the only shop running RANCID (ports/net-mgmt/rancid) on FreeBSD (since it is quite popular in ISP environments), so hopefully someone can look at it from the RANCID angle and give some helpful input on how to troubleshoot this further. The problem: After finally giving in and starting to phase out some of our oldest FreeBSD 4.11 servers and replace them with FreeBSD 6.x on some fresh hardware, I got around to start moving our RANCID server. This however, has been the start of a real nightmare. I don't think the problems I am seeing are in RANCID itself, however it can be reliable reproduced every time i run RANCID and I have not been able to reproduce it in any other way with pure expect test-cases directly. What happens: Expect processes hang during RANCID runs, and go into infinite loops eating 100% CPU (on one CPU core). The problem is reliably reproduced everytime we do a full rancid-run, but the actual device it chokes on varies between runs so it is not device-related. It does seem to happen most often when collecting Juniper M-series gear with large configurations though, using jrancid and ssh. We can NOT seem to reproduce it by running jrancid (or any other) on a single device at at time - which is somewhat confusing at is DOES happen when setting PAR_COUNT to 1 and doing a rancid-run (which should IMHO be pretty much the same as doing sequential single device runs...) Our environment: We run RANCID extensively to collect a few hundred devices, including Cisco, Cisco-CatOS, Juniper, Extreme, Extreme-XOS, Riverstone, FortiNet/FortiGate, etc. We want to start storing CPE configs in addition to our own core gear in RANCID now, which means we will be putting several thousand routers into RANCID, which also explains the need for fresher hardware... RANCID version does not seem to matter, I have tested with both some ancient 2.3.0 scripts and 2.3.2a7, same behaviour. Using the same RANCID instance (I have tarballed it up and installed it on a bunch of servers, i.e. using the same CVS and the same router.db files etc.), it fails on: FreeBSD 7.0-BETA4, amd64, SMP kernel, 8 x CPU cores (2 x quad Xeon 5335) FreeBSD 6.2-STABLE, i386, SMP kernel, 2 x CPU cores (2 x single-core Xeon) Both have perl-5.8.8_1, expect 5.43.0_3 and tcl-8.4.16,1 built from ports. It however seems to work fine on: Linux CentOS 4.5 x86-64, 4 x CPU cores (2 x dual Xeon 5130) FreeBSD 4.11 i386, UP kernel, 1 x CPU core (1 x single-core Xeon) FreeBSD 7.0-RC1, i386, UP kernel, 1 x CPU core (1 x P4) (Linux box has Expect 5.42 and Tcl 8.3...) So it only seems to be on newer FreeBSD with SMP. (If anyone have RANCID working okay on FreeBSD 6.x/7.x on SMP systems at all, please let me know...) Now, for some details, if anyone has any ideas. What is actually happening is this, when truss'ing the stuck Expect-process: fcntl(4,F_GETFL,) = 0 (0x0) fcntl(4,F_SETFL,0x0)ERR#25 'Inappropriate ioctl for device' fcntl(4,F_GETFL,) = 0 (0x0) fcntl(4,F_SETFL,0x0)ERR#25 'Inappropriate ioctl for device' looping ad nauseum So, which device is it trying to fcntl, and what is it trying to do? lsof shows the following: expect 1417 rancid cwd VDIR 0,86 2048 7607662 /local/rancid/var/core/configs expect 1417 rancid rtd VDIR 0,81 512 2 / expect 1417 rancid0r VCHR 0,24 0t0 24 /dev/null expect 1417 rancid2r VCHR 0,24 0t0 24 /dev/null expect 1417 rancid3r VCHR 0,24 0t0 24 /dev/null expect 1417 rancid4r VCHR 0,24 0t0 24 /dev/null file descriptor 4 is /dev/null. Why is it trying to F_SETFL /dev/null to BLOCKING mode (which is failing)? Why should it be playing with /dev/null at all? Well, digging a little, this is what the lsof output looked like 10 seconds earlier: expect 1417 rancid cwd VDIR 0,86 2048 7607662 /local/rancid/var/core/configs expect 1417 rancid rtd VDIR 0,81 512 2 / expect 1417 rancid0r VCHR 0,24 0t0 24 /dev/null expect 1417 rancid1u PIPE 0x38bfcf80 -0xff00038bfba0 expect 1417 rancid2w VREG 0,86 76 7583772 /local (/dev/mfid0s1f) expect 1417 rancid3u VCHR 0,108 0t0 108 /dev/ttyp2 expect 1417 rancid4u VCHR 0,117 0t45 117 /dev/ptyp7 ssh1418 rancid cwd VDIR 0,86 2048 7607662 /local/rancid/var/core/configs ssh1418 rancid rtd VDIR 0,81 512 2 / ssh1418 rancid txt
Re: Rancid/Expect failing on FreeBSD/SMP systems
Lars Erik Gullerud wrote: So it only seems to be on newer FreeBSD with SMP. (If anyone have RANCID working okay on FreeBSD 6.x/7.x on SMP systems at all, please let me know...) This probably won't be of much help, I figured I'd chime in anyway since it may effect me in the future, but I just haven't had any trouble with rancid on 7.x yet. It's only been in operation for 11 days though. FreeBSD .x.com 7.0-PRERELEASE FreeBSD 7.0-PRERELEASE #1: Fri Dec 28 21:48:39 EST 2007 CPU: Intel(R) Xeon(TM) CPU 3.06GHz (3059.98-MHz 686-class CPU) Origin = GenuineIntel Id = 0xf29 Stepping = 9 Features=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE Features2=0x4400CNXT-ID,xTPR real memory = 4026376192 (3839 MB) avail memory = 3937681408 (3755 MB) ACPI APIC Table: IBMSERONYXP FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 6 I'm currently monitoring 18 cisco routers using ssh login, probably not enough to trigger the problem. grep -c up router.db 18 pkg_info -r rancid-2.3.1_2 Information for rancid-2.3.1_2: Depends on: Dependency: kbproto-1.0.3 Dependency: inputproto-1.4.2.1 Dependency: tcl-8.4.16,1 Dependency: perl-5.8.8_1 Dependency: p5-Scalar-List-Utils-1.19,1 Dependency: pkg-config-0.22_1 Dependency: xtrans-1.0.4 Dependency: xproto-7.0.10_1 Dependency: libXdmcp-1.0.2 Dependency: libXau-1.0.3_2 Dependency: libX11-1.1.3,1 Dependency: tk-8.4.16,2 Dependency: expect-5.43.0_3 Dependency: p5-PathTools-3.2501 Dependency: p5-CGI.pm-3.31,1 Dependency: p5-LockFile-Simple-0.2.6 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [rancid] Rancid/Expect failing on FreeBSD/SMP systems
Hi Lars, You should use expect-devel port to avoid hunging on pty have a look at http://www.freebsd.org/cgi/query-pr.cgi?pr=118452 Janos Mohacsi Network Engineer, Research Associate, Head of Network Planning and Projects NIIF/HUNGARNET, HUNGARY Key 70EF9882: DEC2 C685 1ED4 C95A 145F 4300 6F64 7B00 70EF 9882 On Thu, 10 Jan 2008, Lars Erik Gullerud wrote: My apologies for posting this both to the Rancid list and FreeBSD-STABLE, however I am not sure where to start troubleshooting this issue - I am suspecting it is a FreeBSD issue, but I am thinking we are probably not the only shop running RANCID (ports/net-mgmt/rancid) on FreeBSD (since it is quite popular in ISP environments), so hopefully someone can look at it from the RANCID angle and give some helpful input on how to troubleshoot this further. The problem: After finally giving in and starting to phase out some of our oldest FreeBSD 4.11 servers and replace them with FreeBSD 6.x on some fresh hardware, I got around to start moving our RANCID server. This however, has been the start of a real nightmare. I don't think the problems I am seeing are in RANCID itself, however it can be reliable reproduced every time i run RANCID and I have not been able to reproduce it in any other way with pure expect test-cases directly. What happens: Expect processes hang during RANCID runs, and go into infinite loops eating 100% CPU (on one CPU core). The problem is reliably reproduced everytime we do a full rancid-run, but the actual device it chokes on varies between runs so it is not device-related. It does seem to happen most often when collecting Juniper M-series gear with large configurations though, using jrancid and ssh. We can NOT seem to reproduce it by running jrancid (or any other) on a single device at at time - which is somewhat confusing at is DOES happen when setting PAR_COUNT to 1 and doing a rancid-run (which should IMHO be pretty much the same as doing sequential single device runs...) Our environment: We run RANCID extensively to collect a few hundred devices, including Cisco, Cisco-CatOS, Juniper, Extreme, Extreme-XOS, Riverstone, FortiNet/FortiGate, etc. We want to start storing CPE configs in addition to our own core gear in RANCID now, which means we will be putting several thousand routers into RANCID, which also explains the need for fresher hardware... RANCID version does not seem to matter, I have tested with both some ancient 2.3.0 scripts and 2.3.2a7, same behaviour. Using the same RANCID instance (I have tarballed it up and installed it on a bunch of servers, i.e. using the same CVS and the same router.db files etc.), it fails on: FreeBSD 7.0-BETA4, amd64, SMP kernel, 8 x CPU cores (2 x quad Xeon 5335) FreeBSD 6.2-STABLE, i386, SMP kernel, 2 x CPU cores (2 x single-core Xeon) Both have perl-5.8.8_1, expect 5.43.0_3 and tcl-8.4.16,1 built from ports. It however seems to work fine on: Linux CentOS 4.5 x86-64, 4 x CPU cores (2 x dual Xeon 5130) FreeBSD 4.11 i386, UP kernel, 1 x CPU core (1 x single-core Xeon) FreeBSD 7.0-RC1, i386, UP kernel, 1 x CPU core (1 x P4) (Linux box has Expect 5.42 and Tcl 8.3...) So it only seems to be on newer FreeBSD with SMP. (If anyone have RANCID working okay on FreeBSD 6.x/7.x on SMP systems at all, please let me know...) Now, for some details, if anyone has any ideas. What is actually happening is this, when truss'ing the stuck Expect-process: fcntl(4,F_GETFL,) = 0 (0x0) fcntl(4,F_SETFL,0x0)ERR#25 'Inappropriate ioctl for device' fcntl(4,F_GETFL,) = 0 (0x0) fcntl(4,F_SETFL,0x0)ERR#25 'Inappropriate ioctl for device' looping ad nauseum So, which device is it trying to fcntl, and what is it trying to do? lsof shows the following: expect 1417 rancid cwd VDIR 0,86 2048 7607662 /local/rancid/var/core/configs expect 1417 rancid rtd VDIR 0,81 512 2 / expect 1417 rancid0r VCHR 0,24 0t0 24 /dev/null expect 1417 rancid2r VCHR 0,24 0t0 24 /dev/null expect 1417 rancid3r VCHR 0,24 0t0 24 /dev/null expect 1417 rancid4r VCHR 0,24 0t0 24 /dev/null file descriptor 4 is /dev/null. Why is it trying to F_SETFL /dev/null to BLOCKING mode (which is failing)? Why should it be playing with /dev/null at all? Well, digging a little, this is what the lsof output looked like 10 seconds earlier: expect 1417 rancid cwd VDIR 0,86 2048 7607662 /local/rancid/var/core/configs expect 1417 rancid rtd VDIR 0,81 512 2 / expect 1417 rancid0r VCHR 0,24 0t0 24 /dev/null expect 1417 rancid1u PIPE 0x38bfcf80 -0xff00038bfba0 expect 1417 rancid2w VREG 0,86 76 7583772 /local (/dev/mfid0s1f) expect 1417 rancid3u VCHR 0,108 0t0 108
Re: What current Dell Systems are supported/work
On Wednesday 09 January 2008 07:06:02 pm Xin LI wrote: Richard Bates wrote: Sorry for the repost... I don't think the first one posted.. posted to freebsd.stable, freebsd-current, Freebsd-hardware I checked the hardware in the online documentation manual/hardware It only lists the bits and peices of the machine say the hard drive controller and so forth. but doesn't give you a particular system to look at as a working machine with FreeBSD 6.2 does anybody know if a Dell PowerEdge 1950 • Quad-Core Intel Xeon Processors 5400 series 3.16GHz • 4GB Ram I am looking to attach 2 machines to a SAN to make a constantly up system. Is there a Dell San and San Switch that will work with this version of BSD? Thank you for your help It has been observed that there is some interrupt related issue with certain models of Dell PowerEdge 1950/2950 on 6.2-RELEASE, to be more specific, those which are configured without a RAID controller. The symptom is that server will hang on boot after detected acd0, but this is not reliably reproducible. If you use 'show intrcnt' in ddb do you see an interrupt storm on bce0? We have a local patch at work to fix an interrupt storm on boot with bce(4) that needs further refinement but I don't have any boxes handy to test on. At our company (we deploy hundreds of 1950/2950 online during last year), our important local changes that is made for these boxes include: - backport my bce(4) changes from RELENG_6. - backport MSI support, and enable by default. (*) *: This is the default behavior for 7.0, I have not encountered the problem mentioned above on any 1950/2950 boxes so far I have tested. I will enable MSI by default on 6.x now (so will take affect for 6.4). We've also enabled it by default on 6.x at work. -- John Baldwin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 7.0BETA4 desktop system also periodically freezes
On Thu, 10 Jan 2008 07:33:03 +0200, Kostik Belousov [EMAIL PROTECTED] wrote:
For the SU-imposed jerkiness, try the patch below. Progress on developing
the change stalled somehow, and I would like to process with it.
diff --git a/sys/kern/vfs_mount.c b/sys/kern/vfs_mount.c
index 248ce22..005f915 100644
--- a/sys/kern/vfs_mount.c
+++ b/sys/kern/vfs_mount.c
@@ -2001,6 +2001,12 @@ __mnt_vnode_next(struct vnode **mvp, struct mount *mp)
mtx_assert(MNT_MTX(mp), MA_OWNED);
KASSERT((*mvp)-v_mount == mp, (marker vnode mount list mismatch));
+ if ((*mvp)-v_yield++ == 500) {
+ MNT_IUNLOCK(mp);
+ (*mvp)-v_yield = 0;
+ uio_yield();
+ MNT_ILOCK(mp);
+ }
vp = TAILQ_NEXT(*mvp, v_nmntvnodes);
while (vp != NULL vp-v_type == VMARKER)
vp = TAILQ_NEXT(vp, v_nmntvnodes);
diff --git a/sys/sys/vnode.h b/sys/sys/vnode.h
index 0525a43..1ac289a 100644
--- a/sys/sys/vnode.h
+++ b/sys/sys/vnode.h
@@ -131,6 +131,7 @@ struct vnode {
struct socket *vu_socket; /* v unix domain net (VSOCK) */
struct cdev *vu_cdev; /* v device (VCHR, VBLK) */
struct fifoinfo *vu_fifoinfo; /* v fifo (VFIFO) */
+ int vu_yield; /* yield count (VMARKER) */
} v_un;
/*
@@ -185,6 +186,7 @@ struct vnode {
#define v_socketv_un.vu_socket
#define v_rdev v_un.vu_cdev
#define v_fifoinfo v_un.vu_fifoinfo
+#define v_yield v_un.vu_yield
/* XXX: These are temporary to avoid a source sweep at this time */
#define v_object v_bufobj.bo_object
diff --git a/sys/ufs/ffs/ffs_softdep.c b/sys/ufs/ffs/ffs_softdep.c
index a221b66..02cf45b 100644
--- a/sys/ufs/ffs/ffs_softdep.c
+++ b/sys/ufs/ffs/ffs_softdep.c
@@ -864,6 +864,7 @@ softdep_process_worklist(mp, full)
*/
if (loopcount++ % 128 == 0) {
FREE_LOCK(lk);
+ uio_yield();
bwillwrite();
ACQUIRE_LOCK(lk);
}
Applied this patch. No change when deleting 1Gb files - the system
still freezes briefly during the deallocation.
-jr
signature.asc
Description: PGP signature
Re: 6.3-PRERELEASE desktop system periodically freezes momentarily
Kris Kennaway wrote: OK. Can you obtain a lock profiling dump? I'm trying, but not succeeding so far. I added the following to the kernel config: options MUTEX_PROFILING options MPROF_BUFFERS=1536 options MPROF_HASH_SIZE=1543 And set debug.mutex.prof.enable=1 However, kgmon says that profiling is not enabled in the kernel. Am I missing something essential or barking under completely wrong tree? ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 6.3-PRERELEASE desktop system periodically freezes momentarily
Toomas Aas wrote: Kris Kennaway wrote: OK. Can you obtain a lock profiling dump? I'm trying, but not succeeding so far. I added the following to the kernel config: options MUTEX_PROFILING options MPROF_BUFFERS=1536 options MPROF_HASH_SIZE=1543 And set debug.mutex.prof.enable=1 However, kgmon says that profiling is not enabled in the kernel. Am I missing something essential or barking under completely wrong tree? Yes :) kgmon has nothing to do with mutex profiling, so remove the MPROF_*. sysctl debug.mutex.prof.enable=1 ... trigger hang ... sysctl debug.mutex.prof.enable=0 and send me the output of sysctl debug.mutex.prof.stats Kris ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Performance!
Krassimir Slavchev wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Kris Kennaway wrote: Krassimir Slavchev wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello, Kris Kennaway wrote: Krassimir Slavchev wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello, Here are lock profiling results with select patch applied. OK, you are doing I/O over TCP. Are you sure you are using TCP on both systems? Linux may not be defaulting to TCP transport for local queries. Add --pgsql-host= to your sysbench command line to make it communicate over a local domain socket, which is much more efficient. Kris Hmm, Yes linux uses local domain sockets! Here are results using local domain sockets on FreeBSD too: #threads#tranzactions/sec 1 728 5 2996 10 5301 20 3931 40 2466 60 1852 80 1424 100 1216 Just to remember: Linux (2.6.18) #threads#transactions/sec 1 693 5 3539 10 5789 20 5791 40 5661 60 5517 80 5401 100 5319 I have results using Fedora 8 on the same hardware: Linux (2.6.23) #threads#transactions/sec 1 740 5 2675 10 6486 20 6893 40 6623 60 6623 80 6522 100 6417 If we look at the results with up to 10 threads the performance of FreeBSD is very good. May be something can be tuned for number of threads number of CPUs? Are you interested in lock profiling statistics with more threads than the number of CPUs? Yes, it's still performing anomalously. Glad we're making progress though :) Kris Okay, but how many threads will be more useful to test with? Let's start with 8 and say 40. The two problems seem to be slightly lower peak and poor scaling above peak. They might be the same, or they might be different. kris ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
FreeBSD tar errors on valid empty tar.gz
Seems our current libarchive? That support FreeBSD's tar implementation has a bug where it can create archives it cant read back. This can be seen by simply creating an empty tar.gz file and then trying to expand or list it. In doing the above you get the following error: tar: Unrecognized archive format: Inappropriate file type or format N.B. gtar can list and expand the created file without issue. Regards Steve This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD tar errors on valid empty tar.gz
On Jan 10, 2008, at 2:58 PM, Steven Hartland wrote: Seems our current libarchive? That support FreeBSD's tar implementation has a bug where it can create archives it cant read back. This can be seen by simply creating an empty tar.gz file and then trying to expand or list it. In doing the above you get the following error: tar: Unrecognized archive format: Inappropriate file type or format N.B. gtar can list and expand the created file without issue. I can't seem to produce this on a 6.3 (prerelease, built mid December 2007) system: 1% touch empty.tar.gz 2% tar ztf empty.tar.gz 3% gtar ztf empty.tar.gz gzip: (stdin): unexpected end of file gtar: Child returned status 1 gtar: Error exit delayed from previous errors 4% tar --version bsdtar 1.9.3 - libarchive 1.9.3 5% gtar --version tar (GNU tar) 1.18 Regards, -- -Chuck ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD tar errors on valid empty tar.gz
A totally empty file is not valid try the following test:- touch empty tar cvzf test.tar.gz --files-from empty tar tvzf test.tar.gz tar: Unrecognized archive format: Inappropriate file type or format tar --version bsdtar 1.2.53 - libarchive 1.2.53 gtar tvzf test.tar.gz gtar --version tar (GNU tar) 1.15.1 Tested on: FreeBSD 6.2-RELEASE-p9 Regards Steve - Original Message - From: Chuck Swiger [EMAIL PROTECTED] I can't seem to produce this on a 6.3 (prerelease, built mid December 2007) system: 1% touch empty.tar.gz 2% tar ztf empty.tar.gz 3% gtar ztf empty.tar.gz gzip: (stdin): unexpected end of file gtar: Child returned status 1 gtar: Error exit delayed from previous errors 4% tar --version bsdtar 1.9.3 - libarchive 1.9.3 5% gtar --version tar (GNU tar) 1.18 Regards, -- -Chuck This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD tar errors on valid empty tar.gz
On Thu, Jan 10, 2008 at 11:55:52PM -, Steven Hartland wrote: A totally empty file is not valid try the following test:- touch empty tar cvzf test.tar.gz --files-from empty tar tvzf test.tar.gz tar: Unrecognized archive format: Inappropriate file type or format tar --version bsdtar 1.2.53 - libarchive 1.2.53 gtar tvzf test.tar.gz gtar --version tar (GNU tar) 1.15.1 Tested on: FreeBSD 6.2-RELEASE-p9 Please send-pr this so tkientzle@ can take action on it. Edwin -- Edwin Groothuis |Personal website: http://www.mavetju.org [EMAIL PROTECTED]| Weblog: http://www.mavetju.org/weblog/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD tar errors on valid empty tar.gz
Steven Hartland wrote: A totally empty file is not valid try the following test:- touch empty tar cvzf test.tar.gz --files-from empty tar tvzf test.tar.gz tar: Unrecognized archive format: Inappropriate file type or format tar --version bsdtar 1.2.53 - libarchive 1.2.53 gtar tvzf test.tar.gz gtar --version tar (GNU tar) 1.15.1 Tested on: FreeBSD 6.2-RELEASE-p9 OK, so it's already fixed? Kris ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD tar errors on valid empty tar.gz
On Thu, Jan 10, 2008 at 11:55:52PM -, Steven Hartland wrote: A totally empty file is not valid try the following test:- touch empty tar cvzf test.tar.gz --files-from empty tar tvzf test.tar.gz tar: Unrecognized archive format: Inappropriate file type or format tar --version bsdtar 1.2.53 - libarchive 1.2.53 gtar tvzf test.tar.gz gtar --version tar (GNU tar) 1.15.1 Tested on: FreeBSD 6.2-RELEASE-p9 No problem on 7.0-BETA3 (amd64); touch empty tar cvzf test.tar.gz --files-from empty tar tvzf test.tar.gz tar --version bsdtar 2.2.5 - libarchive 2.2.4 ls -l empty test.tar.gz -rw-r--r-- 1 rsmith rsmith 0 Jan 11 01:14 empty -rw-r--r-- 1 rsmith rsmith 45 Jan 11 01:14 test.tar.gz Roland -- R.F.Smith http://www.xs4all.nl/~rsmith/ [plain text _non-HTML_ PGP/GnuPG encrypted/signed email much appreciated] pgp: 1A2B 477F 9970 BA3C 2914 B7CE 1277 EFB0 C321 A725 (KeyID: C321A725) pgpv7sajzYW9X.pgp Description: PGP signature
Re: FreeBSD tar errors on valid empty tar.gz
- Original Message - From: Kris Kennaway [EMAIL PROTECTED] Steven Hartland wrote: A totally empty file is not valid try the following test:- touch empty tar cvzf test.tar.gz --files-from empty tar tvzf test.tar.gz tar: Unrecognized archive format: Inappropriate file type or format tar --version bsdtar 1.2.53 - libarchive 1.2.53 gtar tvzf test.tar.gz gtar --version tar (GNU tar) 1.15.1 Tested on: FreeBSD 6.2-RELEASE-p9 OK, so it's already fixed? Not that I'm aware of. gtar works but libarchive tar fails on the file it created. Regards Steve This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD tar errors on valid empty tar.gz
Steven Hartland wrote: - Original Message - From: Kris Kennaway [EMAIL PROTECTED] Steven Hartland wrote: A totally empty file is not valid try the following test:- touch empty tar cvzf test.tar.gz --files-from empty tar tvzf test.tar.gz tar: Unrecognized archive format: Inappropriate file type or format tar --version bsdtar 1.2.53 - libarchive 1.2.53 gtar tvzf test.tar.gz gtar --version tar (GNU tar) 1.15.1 Tested on: FreeBSD 6.2-RELEASE-p9 OK, so it's already fixed? Not that I'm aware of. gtar works but libarchive tar fails on the file it created. Yes, in 6.2. What about the report that it works in 6.3? Kris ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD tar errors on valid empty tar.gz
On Jan 10, 2008, at 4:41 PM, Kris Kennaway wrote: Not that I'm aware of. gtar works but libarchive tar fails on the file it created. Yes, in 6.2. What about the report that it works in 6.3? Indeed. Trying to create a tarball using a non-existent list of files returns an error and generates a 0-byte tgz; as previously shown, BSD tar in 6.3 treats that as an empty archive, which seems reasonable, whereas gtar feeds it to gzip which generates an error: 20% tar cvzf test.tar.gz --files-from empty tar: Couldn't open empty: No such file or directory 21% ls -l test.tar.gz -rw-r--r-- 1 chuck chuck 0 Jan 10 19:42 test.tar.gz 22% tar tvzf test.tar.gz 23% gtar tvzf test.tar.gz gzip: (stdin): unexpected end of file gtar: Child returned status 1 gtar: Error exit delayed from previous errors Regards, -- -Chuck ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD tar errors on valid empty tar.gz
On 11/01/2008, at 11:47 AM, Chuck Swiger wrote: On Jan 10, 2008, at 4:41 PM, Kris Kennaway wrote: Not that I'm aware of. gtar works but libarchive tar fails on the file it created. Yes, in 6.2. What about the report that it works in 6.3? Indeed. Trying to create a tarball using a non-existent list of files returns an error and generates a 0-byte tgz; as previously shown, BSD tar in 6.3 treats that as an empty archive, which seems reasonable, whereas gtar feeds it to gzip which generates an error: 20% tar cvzf test.tar.gz --files-from empty tar: Couldn't open empty: No such file or directory 21% ls -l test.tar.gz -rw-r--r-- 1 chuck chuck 0 Jan 10 19:42 test.tar.gz 22% tar tvzf test.tar.gz 23% gtar tvzf test.tar.gz gzip: (stdin): unexpected end of file gtar: Child returned status 1 gtar: Error exit delayed from previous errors Actually, that's slightly different to the problem, in that its creating a 0 byte tar file (which was always OK) However, the 'empty' file is fine in 6.3 as well 13:19 Fri 11-Jan [EMAIL PROTECTED] [~] tar czf test.tgz --files-from /dev/null 13:19 Fri 11-Jan [EMAIL PROTECTED] [~] tar tvzf test.tgz 13:19 Fri 11-Jan [EMAIL PROTECTED] [~] uname -msr FreeBSD 6.3-RC2 i386 13:19 Fri 11-Jan [EMAIL PROTECTED] [~] ls -l test.tgz -rw-r--r--1 sean sean 45 Jan 11 13:19 test.tgz Regards, -- -Chuck ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable- [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: USB issues (not just Re: PR backlog)
From: Mikhail Teterin [EMAIL PROTECTED] Date: Thu, 27 Dec 2007 12:39:21 -0500 Sender: [EMAIL PROTECTED] ÞÅÔ×ÅÒ 27 ÇÒÕÄÅÎØ 2007 12:33 ÐÏ, M. Warner Losh ÷É ÎÁÐÉÓÁÌÉ: I did the bulk of the work for the 7.0 stuff, at least getting things into the tree. Since I did the work, my last job got totally insane and then I switched jobs. As the old Russian saying went: if vodka interferes with your job, you have to stop working. Which explains why there are not more old Russians. :-) We can all agree that this is long overdue. But we need to make sure of a few critical details so we don't create another mess for ourselves down the line. Seriosly, thank you and do get back to it whenever you can. As to the original issue, I reported the same thing with my Olympus camera. It used to work fine, so this is a regression. It crashes current but simply fails when I use the HPS USB stack. (After a few seconds, the camera simply turns itself off.) As the original posted offered, I can provide a dump and posted the backtrace. I'd really love to be able to download pictures again, but I am not optimistic. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: [EMAIL PROTECTED] Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 pgpadLnjC7dYb.pgp Description: PGP signature
Re: What current Dell Systems are supported/work
Richard, I just bought one of these 2450 servers on ebay the other day, it was pretty cheap and still a good server for DNS here is a link http://search.ebay.com/_W0QQsassZlesmilde when I received the server it shipped with PC-BSD installed, I am going to put RELENG_7 on it, but if you read the site there is a link to a dmesg hope this helps Sam Fourman Jr. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD tar errors on valid empty tar.gz
On Fri, 11 Jan 2008 01:08:59 +0100
Kris Kennaway [EMAIL PROTECTED] wrote:
Steven Hartland wrote:
A totally empty file is not valid try the following test:-
touch empty
tar cvzf test.tar.gz --files-from empty
tar tvzf test.tar.gz tar: Unrecognized archive format: Inappropriate
file type or format
tar --version
bsdtar 1.2.53 - libarchive 1.2.53
gtar tvzf test.tar.gz
gtar --version
tar (GNU tar) 1.15.1
Tested on: FreeBSD 6.2-RELEASE-p9
OK, so it's already fixed?
Seems to work OK on my 7-STABLE system.
Interestingly, if I follow Steven Hartland's recipe (using
--files-from empty), I get a 45-byte .tar.gz file that gzcat's
to 10240 zero bytes, but if I leave the z off the tar commands, I
get an uncompressed file of 1024 zero bytes. Should that happen?
In both cases, tar tvf{,z} doesn't whinge about unrecognized
formats.
Cheers,
--
Andrew
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
