From owner-freebsd-fs@FreeBSD.ORG Mon Sep 10 07:16:03 2007 Return-Path: <owner-freebsd-fs@FreeBSD.ORG> Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0B19016A419 for <freebsd-fs@freebsd.org>; Mon, 10 Sep 2007 07:16:03 +0000 (UTC) (envelope-from nikhil.success@gmail.com) Received: from rv-out-0910.google.com (rv-out-0910.google.com [209.85.198.186]) by mx1.freebsd.org (Postfix) with ESMTP id B5E6113C478 for <freebsd-fs@freebsd.org>; Mon, 10 Sep 2007 07:16:02 +0000 (UTC) (envelope-from nikhil.success@gmail.com) Received: by rv-out-0910.google.com with SMTP id l15so918968rvb for <freebsd-fs@freebsd.org>; Mon, 10 Sep 2007 00:16:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; bh=ZiNJAeq40LE1zFbOSzJTb3vKt6HM65vF/GcvvIIeAsw=; b=BJFHzFIPrLbkeB+SU13eo83G9JqTLS9+QYSPVcoW6ZW4VkW+qCIhPT0iU02VulKNxS52RMG42YiOCHeje14x1irD8R64Dt7xDdl7HMVdXoioDn9qUbZMlgbfv5QAuTelSBWDme+qg0fWwaPZ0hGCry1E0s1tdWlBaUc370fRDZM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=SGoNDJGdxe3GDxijBfavcYsuiTEvAoPlpD5OYfcjEIqkSO6qGVqJEkWhaWg8/qp7GunB4OLn5vwXxgHENkjBql4eB997527dapKV9pmNvshgN/e0CfnvYhDJ2Y33gzJWqNMHLsvWkJoZiPqWZ0GtTkIBKlqBkng/nNdqc1LMrCc= Received: by 10.141.74.17 with SMTP id b17mr1757550rvl.1189408562204; Mon, 10 Sep 2007 00:16:02 -0700 (PDT) Received: by 10.141.82.6 with HTTP; Mon, 10 Sep 2007 00:16:02 -0700 (PDT) Message-ID: <bd8ece810709100016t78d89e7fv6d7e51e91f27f44@mail.gmail.com> Date: Mon, 10 Sep 2007 12:46:02 +0530 From: "Nikhil Gupta" <nikhil.success@gmail.com> To: freebsd-fs@freebsd.org In-Reply-To: <20070908120007.977FA16A503@hub.freebsd.org> MIME-Version: 1.0 References: <20070908120007.977FA16A503@hub.freebsd.org> Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Re: freebsd-fs Digest, Vol 220, Issue 5 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems <freebsd-fs.freebsd.org> List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-fs>, <mailto:freebsd-fs-request@freebsd.org?subject=unsubscribe> List-Archive: <http://lists.freebsd.org/pipermail/freebsd-fs> List-Post: <mailto:freebsd-fs@freebsd.org> List-Help: <mailto:freebsd-fs-request@freebsd.org?subject=help> List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-fs>, <mailto:freebsd-fs-request@freebsd.org?subject=subscribe> X-List-Received-Date: Mon, 10 Sep 2007 07:16:03 -0000 Can anybody help me for sun solaris for the same. On sun solaris, how do we get the similar information of atime as we get o= n linux and bsd using mount command. On 9/8/07, freebsd-fs-request@freebsd.org <freebsd-fs-request@freebsd.org> wrote: > > Send freebsd-fs mailing list submissions to > freebsd-fs@freebsd.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.freebsd.org/mailman/listinfo/freebsd-fs > or, via email, send a message with subject or body 'help' to > freebsd-fs-request@freebsd.org > > You can reach the person managing the list at > freebsd-fs-owner@freebsd.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of freebsd-fs digest..." > > > Today's Topics: > > 1. fetching atime information (Nikhil Gupta) > 2. Re: fetching atime information (Andrew Pantyukhin) > 3. Re: fetching atime information (Bill Vermillion) > 4. noatime on / and /var too ? (Gore Jarold) > 5. net/samba3 faults while try to export fusefs or msdosfs > volumes (Vladimir Grebenschikov) > 6. On-disk indexing for "Project Ideas" page (Nikolay Pavlov) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Fri, 7 Sep 2007 19:07:51 +0530 > From: "Nikhil Gupta" <nikhil.success@gmail.com> > Subject: fetching atime information > To: freebsd-fs@freebsd.org > Message-ID: > <bd8ece810709070637i4955703fu1fb53342a8c1c6f6@mail.gmail.com> > Content-Type: text/plain; charset=3DISO-8859-1 > > Hi all, > > I am trying to find for all partitions whether atime update is enabled or > disabled. > What command can display the atime status (whether enabled or disabled) > information for all partitions on free bsd. > > for eg. in Linux, if I give mount command, it displays properties of each > partitions along with noatime (if atime update is disabled). > > Nikhil > > > ------------------------------ > > Message: 2 > Date: Fri, 7 Sep 2007 18:13:55 +0400 > From: Andrew Pantyukhin <infofarmer@FreeBSD.org> > Subject: Re: fetching atime information > To: Nikhil Gupta <nikhil.success@gmail.com> > Cc: freebsd-fs@freebsd.org > Message-ID: <20070907141354.GB56443@amilo.cenkes.org> > Content-Type: text/plain; charset=3Dus-ascii > > On Fri, Sep 07, 2007 at 07:07:51PM +0530, Nikhil Gupta wrote: > > Hi all, > > > > I am trying to find for all partitions whether atime update is enabled > or > > disabled. > > What command can display the atime status (whether enabled or disabled) > > information for all partitions on free bsd. > > > > for eg. in Linux, if I give mount command, it displays properties of > each > > partitions along with noatime (if atime update is disabled). > > Same here. > % mount|grep noatime > /dev/ad0s1f on /usr (ufs, NFS exported, local, noatime) > > > ------------------------------ > > Message: 3 > Date: Fri, 7 Sep 2007 10:33:59 -0400 > From: Bill Vermillion <bv@wjv.com> > Subject: Re: fetching atime information > To: Nikhil Gupta <nikhil.success@gmail.com> > Cc: freebsd-fs@freebsd.org > Message-ID: <20070907143359.GA94581@wjv.com> > Content-Type: text/plain; charset=3Dus-ascii > > On Fri, Sep 07, 2007 at 19:07 , while impersonating an expert on > the internet, Nikhil Gupta sent this to stdout: > > > Hi all, > > > > I am trying to find for all partitions whether atime update is enabled > or > > disabled. > > What command can display the atime status (whether enabled or disabled) > > information for all partitions on free bsd. > > > > for eg. in Linux, if I give mount command, it displays properties of > each > > partitions along with noatime (if atime update is disabled). > > Another poster showed the output of mount. > > You can also check the /etc/fstab to see and/or change which > file systems you set for 'noatime'. > > Bill > -- > Bill Vermillion - bv @ wjv . com > > > ------------------------------ > > Message: 4 > Date: Fri, 7 Sep 2007 15:17:09 -0700 (PDT) > From: Gore Jarold <gore_jarold@yahoo.com> > Subject: noatime on / and /var too ? > To: freebsd-fs@freebsd.org > Message-ID: <704329.73647.qm@web63015.mail.re1.yahoo.com> > Content-Type: text/plain; charset=3Diso-8859-1 > > For performance, I have always set 'noatime' on my > large data partitions. > > For some odd reason I never bothered to set it on / > and /var ... is there any reason not to do that ? > > I know it won't change much since they are not busy > filesystems, but if there is no risk and no "best > practices" reason _not_ to do it, I might as well... > > right ? > > > > > _________________________________________________________________________= ___________ > Take the Internet to Go: Yahoo!Go puts the Internet in your pocket: mail, > news, photos & more. > http://mobile.yahoo.com/go?refer=3D1GNXIC > > > ------------------------------ > > Message: 5 > Date: Sat, 08 Sep 2007 01:45:09 +0400 > From: Vladimir Grebenschikov <vova@fbsd.ru> > Subject: net/samba3 faults while try to export fusefs or msdosfs > volumes > To: freebsd-fs@freebsd.org > Message-ID: <1189201509.1628.10.camel@localhost> > Content-Type: text/plain > > Hi > > Anybody already found that problem ? Probably some clues ? > > from /var/log/samba.log: > katis (172.22.2.11) connect to service C initially as user vova > (uid=3D207, gid=3D207) (pid 40339) > [2007/09/08 01:34:40, 0] lib/fault.c:fault_report(41) > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > [2007/09/08 01:34:40, 0] lib/fault.c:fault_report(42) > INTERNAL ERROR: Signal 6 in pid 40339 (3.0.25a) > Please read the Trouble-Shooting section of the Samba3-HOWTO > [2007/09/08 01:34:40, 0] lib/fault.c:fault_report(44) > > > -- > Vladimir B. Grebenschikov > vova@fbsd.ru > > > ------------------------------ > > Message: 6 > Date: Sat, 8 Sep 2007 12:43:44 +0300 > From: Nikolay Pavlov <qpadla@gmail.com> > Subject: On-disk indexing for "Project Ideas" page > To: freebsd-fs@freebsd.org, freebsd-current@freebsd.org > Message-ID: <200709081243.48890.qpadla@gmail.com> > Content-Type: text/plain; charset=3D"utf-8" > > Recently while reading "Design and Implementation of FreeBSD operation > system" by Marshall Kirk McKusick and gnn i have found a very intresting > paragraph regarding UFS2 implementation, indexing and B-trees. According > to it on-disk indexes was not implemented, but some structures was > reserved for future development. May be some SOC students could implement > this in future. How about to adding this into Project Ideas page? > Let me quote from the paragraph "8.3 Naming": > > Finding of Names in Directories > > A common request to the filesystem is to lookup a specific name in a > directory. The kernel usually does the lookup by starting at the beginnin= g > of the directory and going through, comparing each entry in turn. First, > the length of the sought-after name is compared with the length of the > name being checked. If the lengths are identical, a string comparison of > the name being sought and the directory entry is made. If they match, the > search is complete; if they fail, either in the length or in the string > comparison, the search continues with the next entry. Whenever a name is > found, its name and containing directory are entered into the systemwide > name cache described in Section 6.6. Whenever a search is unsuccessful, a= n > entry is made in the cache showing that the name does not exist in the > particular directory. Before starting a directory scan, the kernel looks > for the name in the cache. If either a positive or negative entry is > found, the directory scan can be avoided. > > Another common operation is to lookup all the entries in a directory. For > example, many programs do a stat system call on each name in a directory > in the order that the names appear in the directory. To improve > performance for these programs, the kernel maintains the directory offset > of the last successful lookup for each directory. Each time that a lookup > is done in that directory, the search is started from the offset at which > the previous name was found (instead of from the beginning of the > directory). For programs that step sequentially through a directory with = n > files, search time decreases from Order(n2) to Order(n). > > One quick benchmark that demonstrates the maximum effectiveness of the > cache is running the ls -l command on a directory containing 600 files. O= n > a system that retains the most recent directory offset, the amount of > system time for this test is reduced by 85 percent. Unfortunately, the > maximum effectiveness is much greater than the average effectiveness. > Although the cache is 90 percent effective when hit, it is applicable to > only about 25 percent of the names being looked up. Despite the amount of > time spent in the lookup routine itself decreasing substantially, the > improvement is diminished because more time is spent in the routines that > that routine calls. Each cache miss causes a directory to be accessed > twice=97once to search from the middle to the end and once to search from > the beginning to the middle. > > These caches provide good directory lookup performance but are ineffectiv= e > for large directories that have a high rate of entry creation and > deletion. Each time a new directory entry is created, the kernel must sca= n > the entire directory to ensure that the entry does not already exist. Whe= n > an existing entry is deleted, the kernel must scan the directory to find > the entry to be removed. For directories with many entries these linear > scans are time-consuming. > > The approach to solving this problem in FreeBSD 5.2 is to introduce > dynamic > directory hashing that retrofits a directory indexing system to UFS [Dows= e > & Malone, 2002]. To avoid repeated linear searches of large directories, > the dynamic directory hashing builds a hash table of directory entries on > the fly when the directory is first accessed. This table avoids directory > scans on later lookups, creates, and deletes. Unlike filesystems > originally designed with large directories in mind, these indices are not > saved on disk and so the system is backward compatible. The drawback is > that the indices need to be built the first time that a large directory i= s > encountered after each system reboot. The effect of the dynamic directory > hashing is that large directories in UFS cause minimal performance > problems. > > When we built UFS2, we contemplated solving the large directory update > problem by changing to a more complex directory structure such as one tha= t > uses B-trees. This technique is used in many modern filesystems such as > XFS [Sweeney et al., 1996], JFS [Best & Kleikamp, 2003], ReiserFS [Reiser= , > 2001], and in later versions of Ext2 [Phillips, 2001]. We decided not to > make the change at the time that UFS2 was first implemented for several > reasons. First, we had limited time and resources, and we wanted to get > something working and stable that could be used in the time frame of > FreeBSD 5.2. By keeping the same directory format, we were able to reuse > all the directory code from UFS1, did not have to change numerous > filesystem utilities to understand and maintain a new directory format, > and were able to produce a stable and reliable filesystem in the time > frame available to us. The other reason that we felt that we could retain > the existing directory structure is because of the dynamic directory > hashing that was added to FreeBSD. > > Borrowing the technique used by the Ext2 filesystem a flag was also added > to show that an on-disk indexing structure is supported for directories > [Phillips, 2001]. This flag is unconditionally turned off by the existing > implementation of UFS. In the future, if an implementation of an on-disk > directory-indexing structure is added, the implementations that support i= t > will not turn the flag off. Index-supporting kernels will maintain the > indices and leave the flag on. If an old non-index-supporting kernel is > run, it will turn off the flag so that when the filesystem is once again > run under a new kernel, the new kernel will discover that the indexing > flag has been turned off and will know that the indices may be out date > and have to be rebuilt before being used. The only constraint on an > implementation of the indices is that they have to be an auxiliary data > structure that references the old linear directory format. > > > -- > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > - Best regards, Nikolay Pavlov. <<<----------------------------------- > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > -------------- next part -------------- > A non-text attachment was scrubbed... > Name: not available > Type: application/pgp-signature > Size: 189 bytes > Desc: This is a digitally signed message part. > Url : > http://lists.freebsd.org/pipermail/freebsd-fs/attachments/20070908/00697f= f9/attachment-0001.pgp > > ------------------------------ > > _______________________________________________ > freebsd-fs@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-fs > To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" > > > End of freebsd-fs Digest, Vol 220, Issue 5 > ****************************************** >