From owner-freebsd-fs Sun Dec 17 14:52: 6 2000 From owner-freebsd-fs@FreeBSD.ORG Sun Dec 17 14:52:03 2000 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from salmon.maths.tcd.ie (salmon.maths.tcd.ie [134.226.81.11]) by hub.freebsd.org (Postfix) with SMTP id BB0FE37B400; Sun, 17 Dec 2000 14:52:02 -0800 (PST) Received: from hamilton.maths.tcd.ie by salmon.maths.tcd.ie with SMTP id ; 17 Dec 2000 22:52:01 +0000 (GMT) To: julian@freebsd.org, mckusick@mckusick.com Cc: freebsd-fs@freebsd.org, iedowse@maths.tcd.ie Subject: creat(2) not setting mtime on existing 0-length file Date: Sun, 17 Dec 2000 22:52:00 +0000 From: Ian Dowse Message-ID: <200012172252.aa18426@salmon.maths.tcd.ie> Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I was trying to figure out why a very old piece of code we use here had not been working as expected for ages. The code stores the time of certain events in zero-length timestamp files using something like: close(creat(filename, 0666)); This is supposed to set the last-modified time on the file to the current time, but I noticed that it has not been doing so for over a year. This works as expected on FreeBSD 2.2.7, and on other systems I tried, but FreeBSD 3.0 or later does not modify the mtime if the file already exists and has zero size. I traced the problem back to r1.36 of src/sys/ufs/ffs/ffs_inode.c, which includes the following changes to ffs_truncate(): @@ -171,6 +176,8 @@ off_t osize; oip = VTOI(ovp); + if (oip->i_size == length) + return (0); fs = oip->i_fs; if (length < 0) return (EINVAL); @@ -197,6 +204,31 @@ A few lines down from this point is the fragment if (oip->i_size == length) { oip->i_flag |= IN_CHANGE | IN_UPDATE; return (UFS_UPDATE(ovp, 0)); } so I think it is obvious that the code is not working as expected since the condition here will never be true. The commit log message gives no hints except that the patches were obtained from the Whistle development tree. So Julian or Kirk, do you have any ideas as to why this change might have been made in r1.36, or if this behaviour is desirable or correct? A quick glance suggests that the problem can be resolved by simply removing the offending lines as in the patch below. Ian Index: ffs_inode.c =================================================================== RCS file: /FreeBSD/FreeBSD-CVS/src/sys/ufs/ffs/ffs_inode.c,v retrieving revision 1.66 diff -u -r1.66 ffs_inode.c --- ffs_inode.c 2000/12/13 08:30:30 1.66 +++ ffs_inode.c 2000/12/17 22:33:59 @@ -151,8 +151,6 @@ off_t osize; oip = VTOI(ovp); - if (oip->i_size == length) - return (0); fs = oip->i_fs; if (length < 0) return (EINVAL); To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Tue Dec 19 5:45:11 2000 From owner-freebsd-fs@FreeBSD.ORG Tue Dec 19 05:45:09 2000 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from localhost.hanmail.net (unknown [211.62.252.63]) by hub.freebsd.org (Postfix) with ESMTP id 0A1AF37B400 for ; Tue, 19 Dec 2000 05:45:08 -0800 (PST) Received: from www9.hanmail.net (www9.hanmail.net [211.32.117.29]) by localhost.hanmail.net (8.10.0/8.9.1) with ESMTP id eBJDdBA08806; Tue, 19 Dec 2000 22:39:11 +0900 Received: (from hanadmin@localhost) by www9.hanmail.net (8.10.0/8.9.1) id eBJBgoM04390; Tue, 19 Dec 2000 20:42:50 +0900 (KST) X-Originating-IP: [150.183.110.36] From: "이윤희" Reply-To: "이윤희" Organization: To: freebsd-fs@FreeBSD.ORG Subject: I want to know about the FreeBSD kernel.. X-Mailer: Daum Web Mailer 1.0 Date: Tue, 19 Dec 2000 20:42:50 KST Message-Id: <20001219204250.HM.80000000001OvNY@www9.hanmail.net> Errors-To: MIME-Version: 1.0 Content-Type: text/plain; charset=euc-kr Content-Transfer-Encoding: 8bit Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi I have studied FreeBSD. I have some Question. First, I want to know file name or function that implement the algorithm which allocate the inode on the disk to in-core inode. Second, I want to know file name or function that implement the algorithm which write in-core inode to the disk when in-core inode was updated. third, can you recomend for me the URL that have many documentations for FreeBSD file system. please help me thank you.. ================================================== 우리 인터넷, Daum 평생 쓰는 무료 E-mail 주소 한메일넷 지구촌 한글 검색서비스 Daum FIREBALL NO SPAM 캠페인! : http://www.daum.net/event/nospam http://www.daum.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Tue Dec 19 8: 3:56 2000 From owner-freebsd-fs@FreeBSD.ORG Tue Dec 19 08:03:53 2000 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id 80DEF37B404; Tue, 19 Dec 2000 08:03:50 -0800 (PST) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id DAA08214; Wed, 20 Dec 2000 03:03:33 +1100 Date: Wed, 20 Dec 2000 03:04:00 +1100 (EST) From: Bruce Evans X-Sender: bde@besplex.bde.org To: Ian Dowse Cc: julian@FreeBSD.ORG, mckusick@mckusick.com, freebsd-fs@FreeBSD.ORG Subject: Re: creat(2) not setting mtime on existing 0-length file In-Reply-To: <200012172252.aa18426@salmon.maths.tcd.ie> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sun, 17 Dec 2000, Ian Dowse wrote: > I was trying to figure out why a very old piece of code we use here > had not been working as expected for ages. The code stores the time > of certain events in zero-length timestamp files using something like: > > close(creat(filename, 0666)); > > This is supposed to set the last-modified time on the file to the > current time, but I noticed that it has not been doing so for over > a year. This works as expected on FreeBSD 2.2.7, and on other > systems I tried, but FreeBSD 3.0 or later does not modify the mtime > if the file already exists and has zero size. > > I traced the problem back to r1.36 of src/sys/ufs/ffs/ffs_inode.c, > which includes the following changes to ffs_truncate(): > > @@ -171,6 +176,8 @@ > off_t osize; > > oip = VTOI(ovp); > + if (oip->i_size == length) > + return (0); > fs = oip->i_fs; > if (length < 0) > return (EINVAL); I fixed this a couple of years ago locally after NIST PCTS found the bug, but never got around to committing the fix. Some standards-related points: - creat(2) is implemented as open(..., ... O_TRUNC). - open(..., ... O_TRUNC) implemented by calling ffs_ftruncate() (via VOP_SETATTR()) with length = 0. - POSIX.1-1990 specifies that open(2) with the O_TRUNC flag set shall mark the times for update upon successful completion. - the Single Unix Spec (version 2, Copyright 1997) specifies that ftruncate(2) shall mark the times for update on successful completion if the file size changed. - POSIX.1-1996 specifies that ftruncate(2) shall mark the times for update on successful completion. Summary: the change gives bug for bug compatibility with the Single Unix Spec for ftruncate(), but breaks the POSIX spec for open() and ftruncate(). > @@ -197,6 +204,31 @@ > > A few lines down from this point is the fragment > > if (oip->i_size == length) { > oip->i_flag |= IN_CHANGE | IN_UPDATE; > return (UFS_UPDATE(ovp, 0)); > } > > so I think it is obvious that the code is not working as expected > since the condition here will never be true. The commit log message > gives no hints except that the patches were obtained from the > Whistle development tree. > > So Julian or Kirk, do you have any ideas as to why this change > might have been made in r1.36, or if this behaviour is desirable > or correct? A quick glance suggests that the problem can be resolved > by simply removing the offending lines as in the patch below. I originally thought that the change was to fix ftruncate(), since doing nothing for the nothing-to-do case is reasonable and is permitted by the Single Unix Spec, but that the implementation was wrong since it broke open(). Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Tue Dec 19 21:17:50 2000 From owner-freebsd-fs@FreeBSD.ORG Tue Dec 19 21:17:41 2000 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from beastie.mckusick.com (beastie.mckusick.com [209.31.233.184]) by hub.freebsd.org (Postfix) with ESMTP id 5B07B37B400; Tue, 19 Dec 2000 21:17:40 -0800 (PST) Received: from beastie.mckusick.com (localhost [127.0.0.1]) by beastie.mckusick.com (8.9.3/8.9.3) with ESMTP id QAA30900; Tue, 19 Dec 2000 16:43:15 -0800 (PST) (envelope-from mckusick@beastie.mckusick.com) Message-Id: <200012200043.QAA30900@beastie.mckusick.com> To: dbhague@allstor-sw.co.uk Subject: Re: Filesystem Crashes Cc: gibbs@scsiguy.com, mjacob@feral.com, Andre Albsmeier , Matt Dillon , freebsd-scsi@FreeBSD.org, freebsd-fs@FreeBSD.org In-Reply-To: Your message of "Wed, 15 Nov 2000 09:48:54 GMT." <80256998.0035EB4C.00@mail.plasmon.co.uk> Date: Tue, 19 Dec 2000 16:43:15 -0800 From: Kirk McKusick Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org From: dbhague@allstor-sw.co.uk To: Kirk McKusick Date: Wed, 15 Nov 2000 09:48:54 +0000 Subject: Re: Filesystem Crashes Kirk, I enclose the test program that we used to trigger the filesystem bug. I have made numerous posting to the FS and SCSI bug lists with details of our problem. The program basically generates a large number of small files and then deletes them. This is designed to stress the meta-data of the filesystem. You should be aware that we now believe this to be a problem with the RAID controller, in particular the lengths of the EIDE cables. However several people have used this program and had filesystem problems. Let me know if I can help further. Regards Dave Just a quick note to bring you up to date with our current thinking. The dup allocation and other block allocation panics seem to be derived from a bug in the buffer caching code which fails to properly write partial-page sized blocks (cylinder group maps which are the data structure that is being corrupted is typically 2K or 3K in size). Matt Dillion and I have been trying to track it down. The jury is still out on whether we have found the bug, but we have found and fixed several suspect pieces of code. If you are still getting these types of panics in -current code, please let Matt and I know. Kirk McKusick =-=-=-=-=-=-=-= Sent by: David Barrett-Hague To: freebsd-scsi@FreeBSD.org, freebsd-fs@FreeBSD.org cc: gibbs@scsiguy.com, mjacob@feral.com, Andre Albsmeier , Steven McIntyre/ALLSTOR/UK/Plasmon@PlasNotes Subject: Re: Stressed SCSI subsystem locks up the system (Document link not converted) This is increasingly looking like a filesystem issue. We have done some more testing on the 4.1 build. We believe the issues with 4.1 are different to the ones with 3.0. Due to the age of 3.0 we have decide to forget about it and concentrate on the 4.1 issues. We have two 4.1 test systems; one failed with the following on the console > dev #da/3 block=0 fs=/RAID blocks >panic ffs_blkfree freeing free frags >syncing disk The system was locked in this state and was ping-able but we could not telnet in. The other system is still running after two days. This is the longest a test has run. The only difference we can see between the systems is the way the filesystem was built. This was built by > dd if=/dev/zero of=/dev/rda0 count=2048 > disklabel -Brw da0 auto > disklabel -e da0 > newfs /dev/rda0d normally this is done in a script which effectively does > disklabel -rw da0 auto > dd if=/dev/zero of=/dev/rda0 count=2048 > disklabel -rw da0 auto > "disklabel" | disklabel -rR da0 > newfs /dev/rda0d The only real difference is the -B option in disklabel. We do not attempt to boot from this partition so this should not matter. Let me know what you think ? Regards Dave For the sake of Freebsd-fs subscribers: For your information we are a small software company, just south of Cambridge UK, and have a thin server that is running FreeBSD. We are developing a storage system which controls a RAID system and automatically archives the data to optical jukeboxes or tape libraries. Basically HSM in a box. The system is as follows: Single board computer, AMD K6-II, 128MB RAM, Adaptec AHA 3940AU Intel Ethernet Pro 100 This is attached to a RAID system although we have had the same failure with a single SCSI drive. I enclose the test script and the source for the main test program. tmcp.c. The test is started with "golongmulti 7" If you require any further information please ask, or give me a call +44-1763-264-474. Thanks Dave (See attached file: tmcp.c)(See attached file: golong) (See attached file: golongmulti)(See attached file: go) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message