freebsd-fs Digest, Vol 220, Issue 5

[Nikhil Gupta]

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 on
linux and bsd using mount command.


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
> ******************************************
>