From owner-freebsd-fs Sun Jan 9 17: 4:23 2000 Delivered-To: freebsd-fs@freebsd.org Received: from knecht.Sendmail.ORG (knecht.sendmail.org [209.31.233.176]) by hub.freebsd.org (Postfix) with ESMTP id 9951014C2F for ; Sun, 9 Jan 2000 17:04:07 -0800 (PST) (envelope-from mckusick@flamingo.McKusick.COM) Received: from flamingo.McKusick.COM (root@flamingo.mckusick.com [209.31.233.178]) by knecht.Sendmail.ORG (8.10.0.Beta10/8.10.0.Beta10) with ESMTP id e0A146J37009; Sun, 9 Jan 2000 17:04:06 -0800 (PST) Received: from flamingo.McKusick.COM (mckusick@localhost [127.0.0.1]) by flamingo.McKusick.COM (8.9.3/8.9.0) with ESMTP id QAA13394; Sun, 9 Jan 2000 16:12:49 -0800 (PST) Message-Id: <200001100012.QAA13394@flamingo.McKusick.COM> To: Matthew Dillon Subject: Soft Update Checkin Cc: dg@root.com, fs@freebsd.org Date: Sun, 09 Jan 2000 16:12:48 -0800 From: Kirk McKusick Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I have completed the checkin of the performance changes in the state that you have been testing. They should show up on your next system update. I enclose the log summary below. ~Kirk =-=-=-=-=-= SCCS/s.ffs_softdep.c: D 9.46 00/01/09 14:58:20 mckusick 86 85 00245/00103/04371 Several performance improvements for soft updates have been added: 1) Fastpath deletions. When a file is being deleted, check to see if it was so recently created that its inode has not yet been written to disk. If so, the delete can proceed to immediately free the inode. 2) Background writes: No file or block allocations can be done while the bitmap is being written to disk. To avoid these stalls, the bitmap is copied to another buffer which is written thus leaving the original available for futher allocations. 3) Link count tracking. Constantly track the difference in i_effnlink and i_nlink so that inodes that have had no change other than i_effnlink need not be written. 4) Identify buffers with rollback dependencies so that the buffer flushing daemon can choose to skip over them. D 9.45 00/01/09 14:40:48 mckusick 85 84 00023/00021/04451 Keep tighter control of removal dependencies by limiting the number of dirrem structure rather than the collaterally created freeblks and freefile structures. Limit the rate of buffer dirtying during periods of intense file removal. D 9.44 00/01/09 14:19:25 mckusick 84 83 00021/00025/04451 Reorganize softdep_fsync so that it only does the inode-is-flushed check before the inode is unlocked while grabbing its parent directory. Once it is unlocked, other operations may slip in that could make the inode-is-flushed check fail. Allowing other writes to the inode before returning from fsync does not break the semantics of fsync since we have flushed everything that was dirty at the time of the fsync call. D 9.43 00/01/09 13:44:42 mckusick 83 82 00017/00011/04459 Make static non-exported functions D 9.42 00/01/09 13:34:14 mckusick 82 81 00001/00001/04469 The function request_cleanup() had a tsleep() with PCATCH. It is quite dangerous, since the process may hold locks at the point, and if it is stopped in that tsleep the machine may hang. Because the sleep is so short, the PCATCH is not required here, so it has been removed. From Dmitrij Tejblum D 9.41 00/01/09 13:32:38 mckusick 81 80 00179/00141/04291 Conversion from BSD/OS to FreeBSD code base To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Fri Jan 14 12:51:17 2000 Delivered-To: freebsd-fs@freebsd.org Received: from altair.origenbio.com (altair.origenbio.com [216.30.62.130]) by hub.freebsd.org (Postfix) with ESMTP id 7D79115225 for ; Fri, 14 Jan 2000 12:51:13 -0800 (PST) (envelope-from dmartin@origen.com) Received: from origen.com (dubhe.origen [192.168.0.5]) by altair.origenbio.com (8.9.3/8.9.3) with ESMTP id OAA27240 for ; Fri, 14 Jan 2000 14:51:09 -0600 (CST) (envelope-from dmartin@origen.com) Message-ID: <387F8C0B.5E900178@origen.com> Date: Fri, 14 Jan 2000 14:50:19 -0600 From: Richard Martin X-Mailer: Mozilla 4.6 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: freebsd-fs@FreeBSD.ORG Subject: CD-R Mounting Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I can't seem to mount custom CD-Rs on our FreeBSD systems. The CDs in question mount fine on other plain CD readers on both NT and Linux systems, however, I cannot mount them on F'BSD. I can eliminate hardware because the same system mounted these when it was Linux a few weeks ago. Is there a special mount flag or fs for CD-Rs burned with Adaptec software? No help from Adaptec, and I can't seem to locate anything in the knowledge base or in the local users' group. Thanks, -- Richard Martin dmartin@origen.com OriGen Biomedical Tel: +1 512 474 7278 2525 Hartford Rd. Fax: +1 512 708 8522 Austin, TX 78703 http://www.formed.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message