Re: Please help with cleaning up an accident on 9.0 release
On Tue, May 19, 2015 at 07:23:56AM -0800, Royce Williams wrote: > On Tue, May 19, 2015 at 7:15 AM, Ulrich Drolshagen > wrote: > > > Hi all, > > > > I brought myself in real trouble with a really important 9.0 release > > system (9.0-RELEASE-p4). It's amd64. By accident I deleted the following > > binaries from /bin: cat, chflags, chio, chmod and cp > > Does anybody still have an old iso from which he can extract these > > binaries for me please? > > > > I would be really thankful if anybody could help > > > > Here you go: > > http://www.techsolvency.com/tmp/ > And all of them have statically compiled versions in /rescue pgpJBMc0r0nnt.pgp Description: PGP signature
Re: table with bug in ipfw
19.05.2015, 03:22, "Marcelo Gondim" : > Hi all, Hi, > > I see that there is still the following bug in ipfw: > > # ipfw table 33 add 0.0.0.0/8 > # ipfw table 33 list > ::/8 0 > > and > > # ipfw table 33 add 255.255.255.255 > # ipfw table 33 list > ::/8 0 > > The IP 255.255.255.255 not appear but it's there. Look below: > > # ipfw table 33 add 255.255.255.255 > ipfw: setsockopt(IP_FW_TABLE_XADD): File exists > > This is very ugly to see. As it was not fixed in 10.1, would be expected > to 10.2? It was fixed in -head but didn't get to -stable. I'll try to take a look soon. > > Best regards, > Gondim > > ___ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
L2ARC degraded. Checksum errors, I/O errors
Hello, Appologies if that has been asked before. I was wondering if the following bug has been addressed so far: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=198242 Thanks -- George Kontostanos --- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: L2ARC degraded. Checksum errors, I/O errors
On Wed, May 20, 2015 at 07:17:44PM +0300, George Kontostanos wrote: > Hello, > > Appologies if that has been asked before. I was wondering if the following > bug has been addressed so far: > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=198242 As I know kstat.zfs.misc.arcstats.l2_cksum_bad: 14495 kstat.zfs.misc.arcstats.l2_io_error: 12877 caused by hardware failure on L2ARC device. try replace it. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: L2ARC degraded. Checksum errors, I/O errors
Den 20 maj 2015 7:50 em skrev Slawa Olhovchenkov : > > On Wed, May 20, 2015 at 07:17:44PM +0300, George Kontostanos wrote: > > > Hello, > > > > Appologies if that has been asked before. I was wondering if the following > > bug has been addressed so far: > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=198242 > > As I know > > kstat.zfs.misc.arcstats.l2_cksum_bad: 14495 > kstat.zfs.misc.arcstats.l2_io_error: 12877 > > caused by hardware failure on L2ARC device. > try replace it. Hardly. We are seeing this phenomenon on all of your ZFS storage's, where some of the L2ARC's are new, so I'd be very surprised if these are real hardware failures. That, as well as being reported by so many, my vote is on bug. @gkontos Thanks for bringing this to attention, I'm also interested in hearing if anyone's working on this. /K > ___ > freebsd...@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-fs > To unsubscribe, send any mail to "freebsd-fs-unsubscr...@freebsd.org" ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: L2ARC degraded. Checksum errors, I/O errors
On Wed, May 20, 2015 at 9:53 PM, Karli Sjöberg wrote: > > Den 20 maj 2015 7:50 em skrev Slawa Olhovchenkov : > > > > On Wed, May 20, 2015 at 07:17:44PM +0300, George Kontostanos wrote: > > > > > Hello, > > > > > > Appologies if that has been asked before. I was wondering if the > following > > > bug has been addressed so far: > > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=198242 > > > > As I know > > > > kstat.zfs.misc.arcstats.l2_cksum_bad: 14495 > > kstat.zfs.misc.arcstats.l2_io_error: 12877 > > > > caused by hardware failure on L2ARC device. > > try replace it. > > Hardly. We are seeing this phenomenon on all of your ZFS storage's, where > some of the L2ARC's are new, so I'd be very surprised if these are real > hardware failures. That, as well as being reported by so many, my vote is > on bug. > > @gkontos > Thanks for bringing this to attention, I'm also interested in hearing if > anyone's working on this. > > /K > Thanks, I am ignoring the previous comment as it makes no real sense. > > ___ > > freebsd...@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-fs > > To unsubscribe, send any mail to "freebsd-fs-unsubscr...@freebsd.org" > -- George Kontostanos --- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: L2ARC degraded. Checksum errors, I/O errors
Den 20 maj 2015 9:40 em skrev George Kontostanos : > > > > On Wed, May 20, 2015 at 9:53 PM, Karli Sjöberg wrote: >> >> >> Den 20 maj 2015 7:50 em skrev Slawa Olhovchenkov : >> > >> > On Wed, May 20, 2015 at 07:17:44PM +0300, George Kontostanos wrote: >> > >> > > Hello, >> > > >> > > Appologies if that has been asked before. I was wondering if the >> > > following >> > > bug has been addressed so far: >> > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=198242 >> > >> > As I know >> > >> > kstat.zfs.misc.arcstats.l2_cksum_bad: 14495 >> > kstat.zfs.misc.arcstats.l2_io_error: 12877 >> > >> > caused by hardware failure on L2ARC device. >> > try replace it. >> >> Hardly. We are seeing this phenomenon on all of your ZFS stora hela, where >> some of the L2ARC's are new, so I'd be very surprised if these are real >> hardware failures. That, as well as being reported by so many, my vote is on >> bug. >> >> @gkontos >> Thanks for bringing this to attention, I'm also interested in hearing if >> anyone's working on this. >> >> /K > > > Thanks, I am ignoring the previous comment as it makes no real sense. Whoops! 's/your ZFS storage's/our ZFS storage's/' :) /K > >> >> > ___ >> > freebsd...@freebsd.org mailing list >> > http://lists.freebsd.org/mailman/listinfo/freebsd-fs >> > To unsubscribe, send any mail to "freebsd-fs-unsubscr...@freebsd.org" > > > > > -- > George Kontostanos > --- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Status of NFS4.1 FS_RECLAIM in FreeBSD 10.1?
Hello, I have not delved too deeply into either the NFS spec or the FreeBSD nfsd code, but from my admittedly-limited understanding, it seems that reclaim is both a mandatory feature and one that is present in the current FreeBSD NFS v4.1 implementation. Is my understanding of this correct? My reason for asking is when attempting to migrate an ESXi server to a FreeBSD NFSv4.1 datastore, ESXi throws the following error: > WARNING: NFS41: NFS41FSCompleteMount:3601: RECLAIM_COMPLETE FS failed: Not > supported; forcing read-only operation VMware ESXi 6.0 is able to mount NFSv4.1 shares exported from other operating systems, so I figured I would ask here on the list before digging out a copy of tcpdump and going down that rabbit hole. I can mount and use NFSv3 shares just fine with ESXi from this same server, and can mount the same shares as NFSv4 from other clients (e.g. OS X) as well. Thanks, Mahmoud Al-Qudsi NeoSmart Technologies ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Will iSAT's ALMMS improve my ADSL speed? MailRef#B4-2066030#
Wed 20 May 2015 ADSL Internet access speed is a very common search used in Google and other search engines. It is also regularly hotly debated on Internet forums. Clearly it is a common concern. Assisting to resolve ADSL speed issues is one of the many benefits of iSAT's ADSL line monitoring and management system. ALMMS helps in three key ways: 1. ALMMS helps to keep your line operating at the speed that you are paying for. So if you are paying for a 4 Mbps line, ALMMS will try and get, and keep your line at that speed. To achieve this, iSAT works directly with Telkom, you do not have to contact them yourself. ALMMS will also let you know what your best speed is, and if this is not going to work for you, you can look for an alternative to ADSL. 2. ALMMS monitors and reports on changes on your ADSL line, so if a Telkom infrastructure upgrade is done, and you can then operate at a higher line speed, ALMMS will let you know. 3. And thirdly and very importantly, ALMMS eliminates the ADSL line as part of the ADSL access speed problem. If ALMMS reports that your line is operating optimally, then you know that the problem has nothing to do with your ADSL line. Which means that the problem is with the ADSL access package that you are using. It might not mean that you have a poor access solution, although this is possible, it could be that have chosen the wrong solution. If you are using ADSL for business, you may need to use a more business oriented type of access option. If you are using your ADSL for downloading movies, or playing games, remember that the cheapest access solution is not always the best. Whatever your usage situation, once you know that your ADSL line is working optimally, you can try various access solutions. Most ISP's will not tie you down to a contract. So if you are using ADSL Internet access, you are relying on a Telkom ADSL line. Then there is absolutely no doubt that you need this ADSL line monitoring and management service from iSAT now. This type of product is unique in South Africa and only available from iSAT. And at only R20 a month, it really is a no-brainer. If your ADSL line is not already with iSAT, get it moved today, it'ss an entirely painless process, and your service will not be interrupted at all. If you have other services with a different ISP, leave them as they are, they will continue working, just get the ADSL line moved now, and enable ALMMS immediately. [1]Click here to see some actual examples of what ALMMS does. For an overview about ALMMS [2]click here. For a detailed description of ALMMS [3]click here. ALMMS is making our competitors nervous, please read some common objections and our responses [4]here. For frequently asked questions about ALMMS [5]click here. For general news about ALMMS [6]click here. Sign up now it will only take 5 minutes Sign up on-line (this is the quickest and easiest method, and completely secure), [7]click here. Or Request a form to fill in and fax through to us, [8]click here. It's time for change, help be part of the solution and not part of the problem Kind regards, If you aren't using ADSL access, please forward this email on to someone who is, they will be grateful for your help. And we apologise for taking up your time. This email was sent to freebsd-stable@freebsd.org. Click [9]Unsubscribe to send us a mail to remove this address from our mailing list. If you have any questions, we would love to hear them. Please mail us at [10]al...@isat.co.za References 1. https://www.isat.co.za/products/adsl-line-monitoring-management-system.aspx?examples=true&mailref=B4-2066030 2. https://www.isat.co.za/products/adsl-line-monitoring-management-system.aspx?overview=true&mailref=B4-2066030 3. https://www.isat.co.za/products/adsl-line-monitoring-management-system.aspx?details=true&mailref=B4-2066030 4. https://www.isat.co.za/products/adsl-line-monitoring-management-system.aspx?objections=true&mailref=B4-2066030 5. https://www.isat.co.za/products/adsl-line-monitoring-management-system.aspx?faqs=true&mailref=B4-2066030 6. https://www.isat.co.za/products/adsl-line-monitoring-management-system.aspx?news=true&mailref=B4-2066030 7. https://www.isat.co.za/ordering/adsl-line-monitoring-management-system.aspx?almms=true&mailref=B4-2066030 8. https://www.isat.co.za/documents/isat-almms-registration-form.pdf 9. mailto:al...@isat.co.za?subject=?Subject=unsubscribe%20-freebsd-sta...@freebsd.org 10. mailto:al...@isat.co.za ___ freebsd-stable@
Re: Status of NFS4.1 FS_RECLAIM in FreeBSD 10.1?
Mahoud Al-Qudsi wrote: > Hello, > > I have not delved too deeply into either the NFS spec or the FreeBSD > nfsd > code, but from my admittedly-limited understanding, it seems that > reclaim is > both a mandatory feature and one that is present in the current > FreeBSD NFS > v4.1 implementation. Is my understanding of this correct? > Only the global RECLAIM_COMPLETE is implemented. I'll be honest that I don't even really understand what the "single fs reclaim_complete" semantics are and, as such, it isn't implemented. I think it is meant to be used when a file system is migrated from one server to another (transferring the locks to the new server) or something like that. Migration/replication isn't supported. Maybe someday if I figure out what the RFC expects the server to do for this case. > My reason for asking is when attempting to migrate an ESXi server to > a FreeBSD > NFSv4.1 datastore, ESXi throws the following error: > > > WARNING: NFS41: NFS41FSCompleteMount:3601: RECLAIM_COMPLETE FS > > failed: Not > > supported; forcing read-only operation > This is the first time I've heard of a client using this. The only clients I've ever had the opportunity to test against are Linux, Solaris and the FreeBSD one. > VMware ESXi 6.0 is able to mount NFSv4.1 shares exported from other > operating systems, so I figured I would ask here on the list before > digging > out a copy of tcpdump and going down that rabbit hole. > > I can mount and use NFSv3 shares just fine with ESXi from this same > server, and > can mount the same shares as NFSv4 from other clients (e.g. OS X) as > well. > This is NFSv4.1 specific, so NFSv4.0 should work, I think. Or just use NFSv3. rick > Thanks, > > Mahmoud Al-Qudsi > NeoSmart Technologies > > ___ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to > "freebsd-stable-unsubscr...@freebsd.org" > ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Status of NFS4.1 FS_RECLAIM in FreeBSD 10.1?
On May 20, 2015, at 8:57 PM, Rick Macklem wrote: > Only the global RECLAIM_COMPLETE is implemented. I'll be honest that > I don't even really understand what the "single fs reclaim_complete" > semantics are and, as such, it isn't implemented. Thanks for verifying that. > I think it is meant to be used when a file system is migrated from > one server to another (transferring the locks to the new server) or > something like that. > Migration/replication isn't supported. Maybe someday if I figure out > what the RFC expects the server to do for this case. I wasn’t clear on if this was lock reclaiming or block reclaiming. Thanks. >> I can mount and use NFSv3 shares just fine with ESXi from this same >> server, and >> can mount the same shares as NFSv4 from other clients (e.g. OS X) as >> well. >> > This is NFSv4.1 specific, so NFSv4.0 should work, I think. Or just use NFSv3. > > rick For some reason, ESXi doesn’t do ESXi 4.0, only v3 or v4.1. I am using NFS v3 for now, but unless I’m mistaken, since FreeBSD supports neither “nohide” nor “crossmnt” there is no way for a single export(/import) to cross ZFS filesystem boundaries. I am using ZFS snapshots to manage virtual machine images, each machine has its own ZFS filesystem so I can snapshot and rollback individually. But this means that under NFSv3 (so far as I can tell), each “folder” (ZFS fs) must be mounted separately on the ESXi host. I can get around exporting them each individually with the -alldirs parameter, but client-side, there does not seem to be a way of traversing ZFS filesystem mounts without explicitly mounting each and every one - a maintenance nightmare if there ever was one. The only thing I can think of would be unions for the top-level directory, but I’m very, very leery of the the nullfs/unionfs modules as they’ve been a source of system instability for us in the past (deadlocks, undetected lock inversions, etc). That and I really rather a maintenance nightmare than a hack. Would you have any other suggestions? Thanks, Mahmoud ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
