freebsd-fs Digest, Vol 220, Issue 5

Nikhil Gupta nikhil.success at gmail.com
Mon Sep 10 00:14:50 PDT 2007


Thanks for the replies.
One more small query I have.
What output do you get when you give uname command on freebsd.
I am asking this as I donot have access to any freebsd system
Thanks

On 9/8/07, freebsd-fs-request at freebsd.org <freebsd-fs-request at freebsd.org>
wrote:
>
> Send freebsd-fs mailing list submissions to
>         freebsd-fs at 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 at freebsd.org
>
> You can reach the person managing the list at
>         freebsd-fs-owner at 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 at gmail.com>
> Subject: fetching atime information
> To: freebsd-fs at freebsd.org
> Message-ID:
>         <bd8ece810709070637i4955703fu1fb53342a8c1c6f6 at mail.gmail.com>
> Content-Type: text/plain; charset=ISO-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 at FreeBSD.org>
> Subject: Re: fetching atime information
> To: Nikhil Gupta <nikhil.success at gmail.com>
> Cc: freebsd-fs at freebsd.org
> Message-ID: <20070907141354.GB56443 at amilo.cenkes.org>
> Content-Type: text/plain; charset=us-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 at wjv.com>
> Subject: Re: fetching atime information
> To: Nikhil Gupta <nikhil.success at gmail.com>
> Cc: freebsd-fs at freebsd.org
> Message-ID: <20070907143359.GA94581 at wjv.com>
> Content-Type: text/plain; charset=us-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 at yahoo.com>
> Subject: noatime on / and /var too ?
> To: freebsd-fs at freebsd.org
> Message-ID: <704329.73647.qm at web63015.mail.re1.yahoo.com>
> Content-Type: text/plain; charset=iso-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=1GNXIC
>
>
> ------------------------------
>
> Message: 5
> Date: Sat, 08 Sep 2007 01:45:09 +0400
> From: Vladimir Grebenschikov <vova at fbsd.ru>
> Subject: net/samba3 faults while try to export fusefs or msdosfs
>         volumes
> To: freebsd-fs at freebsd.org
> Message-ID: <1189201509.1628.10.camel at 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=207, gid=207) (pid 40339)
> [2007/09/08 01:34:40, 0] lib/fault.c:fault_report(41)
>   ===============================================================
> [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 at fbsd.ru
>
>
> ------------------------------
>
> Message: 6
> Date: Sat, 8 Sep 2007 12:43:44 +0300
> From: Nikolay Pavlov <qpadla at gmail.com>
> Subject: On-disk indexing for "Project Ideas" page
> To: freebsd-fs at freebsd.org, freebsd-current at freebsd.org
> Message-ID: <200709081243.48890.qpadla at gmail.com>
> Content-Type: text/plain; charset="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 beginning
> 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, an
> 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. On
> 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—once 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 ineffective
> for large directories that have a high rate of entry creation and
> deletion. Each time a new directory entry is created, the kernel must scan
> the entire directory to ensure that the entry does not already exist. When
> 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 [Dowse
> & 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 is
> 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 that
> 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 it
> 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.
>
>
> --
> ======================================================================
> - Best regards, Nikolay Pavlov. <<<-----------------------------------
> ======================================================================
>
> -------------- 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/00697ff9/attachment-0001.pgp
>
> ------------------------------
>
> _______________________________________________
> freebsd-fs at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-fs
> To unsubscribe, send any mail to "freebsd-fs-unsubscribe at freebsd.org"
>
>
> End of freebsd-fs Digest, Vol 220, Issue 5
> ******************************************
>


More information about the freebsd-fs mailing list