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: <owner-freebsd-fs@FreeBSD.ORG>
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 <aa18426@salmon>; 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 <iedowse@maths.tcd.ie>
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: <owner-freebsd-fs@FreeBSD.ORG>
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 <freebsd-fs@FreeBSD.ORG>; 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: "이윤희" <xenith2@hanmail.net>
Reply-To: "이윤희" <xenith2@hanmail.net>
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: <xenith2@hanmail.net>
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: <owner-freebsd-fs@FreeBSD.ORG>
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 <bde@zeta.org.au>
X-Sender: bde@besplex.bde.org
To: Ian Dowse <iedowse@maths.tcd.ie>
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: <Pine.BSF.4.21.0012200226530.289-100000@besplex.bde.org>
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: <owner-freebsd-fs@FreeBSD.ORG>
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 <andre.albsmeier@mchp.siemens.de>,
Matt Dillon <dillon@earth.backplane.com>, 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 <mckusick@mckusick.com>
Sender: owner-freebsd-fs@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.org
From: dbhague@allstor-sw.co.uk
To: Kirk McKusick <mckusick@mckusick.com>
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
<andre.albsmeier@mchp.siemens.de>, 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