toasters

toasters@lists.teaparty.net

13520 discussions

RE: Folder update time
by Alan McLachlan 23 May '03

23 May '03

Hi Chris, I had assumed that atime was stored in the directory entry itself (which would have a pointer to an inode that was a simple list of data blocks), which would have explained the behaviour reported by Jeff Burton in his post. TR2002 ("Filesystem Design for an NFS file server appliance") doesn't specify anything about directory entry contents. The testing you show below seems to nails it, but I will go and have a play when I get a moment just fo see it for myself. Now, even if the directory entry doesn't contain the attributes but is simply a name with a pointer to an inode that contains the file attributes, a change in the file attributes will still require the pointer in the directory entry to be changed to point to the new inode. (WAFL NEVER makes changes to existing inodes, it always writes new ones). Therefore the block containing that directory entry will still need to be rewritten (you seem to imply that it won't). If you are at least partly right it would mean that OnTAP is deliberately ignoring the change to directory entries in order to appear more consistent with traditional filesystem behaviour. This still doesn't help us solve Jeff's problem... -----Original Message----- From: Chris Thompson [mailto:cet1@cus.cam.ac.uk] Sent: Friday, 23 May 2003 12:48 AM To: amclachlan(a)asi.com.au Cc: toasters(a)mathworks.com Subject: Re: Folder update time Alan McLachlan writes: > > A write to a file will change the file size attribute in the directory > entry, which will of course change the mod time on the directory itself. No, it doesn't: $ ls -ld temp temp/foobar drwxr-xr-x 2 cet1 cet1 4096 May 22 11:00 temp -rw-r--r-- 1 cet1 cet1 21 May 22 09:00 temp/foobar $ echo foobar >>temp/foobar $ ls -ld temp temp/foobar drwxr-xr-x 2 cet1 cet1 4096 May 22 11:00 temp -rw-r--r-- 1 cet1 cet1 28 May 22 15:19 temp/foobar > In fact, if you don't have "atime update" turned OFF, even opening a file > will change the directory mod time since the access time attribute for the > file needs to be updated in the directory entry. No, it doesn't: $ ls -ld temp; ls -ldu temp/foobar drwxr-xr-x 2 cet1 cet1 4096 May 22 11:00 temp -rw-r--r-- 1 cet1 cet1 28 May 22 15:17 temp/foobar $ cat temp/foobar Oh what a goose I am foobar $ ls -ld temp; ls -ldu temp/foobar drwxr-xr-x 2 cet1 cet1 4096 May 22 11:00 temp -rw-r--r-- 1 cet1 cet1 28 May 22 15:22 temp/foobar (That was done on a different client from the previous test. Client-side caching can confuse attempts to look at atimes otherwise.) > Remember, in WAFL all metadata lives in files. That includes directories. So > ANY change to a directory entry will cause the modification time on the > directory to be updated. But the directory entry doesn't change. It's the inode that changes. You seem to have confused the two. >> Alan: No I haven't. I had simply assumed that mtime and atime were both stored in the directory entry itself. However, your are wrong here: the directory entry still has to change to reflect the new inode location. The inode doesn't "change", a new version of it is written elsewhere. Don't confuse WAFL with UFS... > This will in turn change the mod time on all > relevant parent directories up to the root. Restate that as "the relevant block in the inode metafile has been changed, so all the index blocks up to the root have to be rewritten as well". >> Alan: See above. All directories must change as well since the inodes their entries point to are relocated as part of the CP. Even if the directory entry has a pointer to the file ino > On a traditional filesystem like > NTFS or UFS this would be a performance disaster as it would generate lots > of additional seeks, so they don't do it. However in WAFL an change to a > file will cause all relevant metadata inodes up to the root inode to be > rewritten [in new locations without seeks] anyway, without a performance > cost. All the changed blocks will (usually) be written close together as part of the next checkpoint. But none of these blocks are directory blocks, or blocks containing the inode for the directory (unless they happen to be the same block as that containing the inode for the file). > Hope this helps. Honestly, I don't think it did. Steve Losen wrote: ] ] My guess is that the application is doing more than a simple file open. ] Perhaps it is an editor that is creating a .bak file or something like ] that. As far as I know, to change the mod time of a directory (folder) ] you need to create, delete, or rename a file in the directory. Simply ] reading or writing an existing file does not change the directory mod ] time. An application could also explicitly set the mod time of the ] directory. Another possibility is that the application is deleting and then re-creating the file, which would certainly change the mtime and ctime of the directory. Jeff Burton didn't make it very clear whether the "simple open" was for reading or writing. ] I can think of one other possibility, but I have doubts since this is ] a NTFS volume. If you create a directory with NFS, then it is not in ] unicode format (unless you specify an option to change this). ] The first time you access the directory via CIFS, it is converted to ] unicode, and this might also trip the directory mod time, but I don't ] know. Of course, this only happens once at the first CIFS access. That obviously changes the directory contents, but does it change its mtime (or even the ctime)? I can't do that experiment here as we aren't licensed for CIFS access. Chris Thompson University of Cambridge Computing Service, Email: cet1(a)ucs.cam.ac.uk New Museums Site, Cambridge CB2 3QH, Phone: +44 1223 334715 United Kingdom. **** ASI Solutions Disclaimer **** The material transmitted may contain confidential and/or privileged material and is intended only for the addressee. If you receive this in error, please notify the sender and destroy any copies of the material immediately. ASI will protect your Privacy according to the 10 Privacy Principles outlined under the new Privacy Act, Dec 2001. This email is also subject to copyright. Any use of or reliance upon this material by persons or entities other than the addressee is prohibited. E-mails may be interfered with, may contain computer viruses or other defects. Under no circumstances do we accept liability for any loss or damage which may result from your receipt of this message or any attachments. **** END OF MESSAGE ****

2 1

RE: Folder update time
by Alan McLachlan 22 May '03

22 May '03

Steve, Jeff, A write to a file will change the file size attribute in the directory entry, which will of course change the mod time on the directory itself. In fact, if you don't have "atime update" turned OFF, even opening a file will change the directory mod time since the access time attribute for the file needs to be updated in the directory entry. Remember, in WAFL all metadata lives in files. That includes directories. So ANY change to a directory entry will cause the modification time on the directory to be updated. This will in turn change the mod time on all relevant parent directories up to the root. On a traditional filesystem like NTFS or UFS this would be a performance disaster as it would generate lots of additional seeks, so they don't do it. However in WAFL an change to a file will cause all relevant metadata inodes up to the root inode to be rewritten [in new locations without seeks] anyway, without a performance cost. Hope this helps. Alan McLachlan Senior Systems Engineer Storage Management Solutions ASI Solutions www.asi.com.au Ph +61 2 6230 1566 Fax +61 2 6230 5343 Mobile +61 428 655644 e-mail amclachlan(a)asi.com.au -----Original Message----- From: Steve Losen [mailto:scl@sasha.acc.virginia.edu] Sent: Thursday, 22 May 2003 7:30 AM To: Jeff Burton Cc: toasters(a)mathworks.com Subject: Re: Folder update time > Anyone know why DOT updates the modification time on a ntfs folder > when a file in that folder is simply opened? This is not the way > it works on our other NT systems. Is this a "feature", a bug, or > just a difference between ntfs and wafl's interpretation of ntfs? > I'm on a F880c running 6.3.1R1....and I'm a unix person so I may > be missing the obvious, but I don't think so. Thanks, > > ______________________________________________________________ > Jeff Burton > Storage Architect Abbott Laboratories > EMAIL: Jeffrey.Burton(a)Abbott.com Dept. GB16/Bldg. AP14B-1 > PHONE: 847-935-5778 100 Abbott Park Rd. > FAX: 847-938-5824 Abbott Park, IL 60064-6042 My guess is that the application is doing more than a simple file open. Perhaps it is an editor that is creating a .bak file or something like that. As far as I know, to change the mod time of a directory (folder) you need to create, delete, or rename a file in the directory. Simply reading or writing an existing file does not change the directory mod time. An application could also explicitly set the mod time of the directory. I can think of one other possibility, but I have doubts since this is a NTFS volume. If you create a directory with NFS, then it is not in unicode format (unless you specify an option to change this). The first time you access the directory via CIFS, it is converted to unicode, and this might also trip the directory mod time, but I don't know. Of course, this only happens once at the first CIFS access. Steve Losen scl(a)virginia.edu phone: 434-924-0640 University of Virginia ITC Unix Support **** ASI Solutions Disclaimer **** The material transmitted may contain confidential and/or privileged material and is intended only for the addressee. If you receive this in error, please notify the sender and destroy any copies of the material immediately. ASI will protect your Privacy according to the 10 Privacy Principles outlined under the new Privacy Act, Dec 2001. This email is also subject to copyright. Any use of or reliance upon this material by persons or entities other than the addressee is prohibited. E-mails may be interfered with, may contain computer viruses or other defects. Under no circumstances do we accept liability for any loss or damage which may result from your receipt of this message or any attachments. **** END OF MESSAGE ****

4 4

Folder update time
by Jeff Burton 22 May '03

22 May '03

Anyone know why DOT updates the modification time on a ntfs folder when a file in that folder is simply opened? This is not the way it works on our other NT systems. Is this a "feature", a bug, or just a difference between ntfs and wafl's interpretation of ntfs? I'm on a F880c running 6.3.1R1....and I'm a unix person so I may be missing the obvious, but I don't think so. Thanks, ______________________________________________________________ Jeff Burton Storage Architect Abbott Laboratories EMAIL: Jeffrey.Burton(a)Abbott.com Dept. GB16/Bldg. AP14B-1 PHONE: 847-935-5778 100 Abbott Park Rd. FAX: 847-938-5824 Abbott Park, IL 60064-6042

3 3

RE: Filer F840 Network Path?
by Jon Evans 22 May '03

22 May '03

This option caused me all sorts of trouble with intermittent network connection failures (I think due to a bug in Microsoft's implementation of this RFC) I would recommend turning it off if you are having any problems at all: ip.tcp.sack.enable off -----Original Message----- From: Stephane Bentebba [mailto:stephane.bentebba@fps.fr] Sent: 19 May 2003 15:14 To: alexis.osorio(a)intek.com.co Cc: NetApp List (E-mail) Subject: Re: Filer F840 Network Path? network path not found ... if you are in 6.3 or 6.4 , check for an option called : ip.tcp.sack.enable check it is on, so turn it off and redo the test , does it works ? sack was still experimental not a long time ago i think , sack from microsoft shouldn't discuss the same way filer's sack talk i think this option should be turn off for a while Helberth Alexis Osorio O. wrote: >I have a F840 on Windows NT Domain? > >Wheni try to mapping the path C$ or any other path of the filer, the system >cannot find the network path. > >In the administrative Tools, "Server Manager" i see the computer, type and >description, selecting the computer and properties i receive the next >message: > >"The network path was not found", please anybody can help me. > > >Thank you very much. > > > >Helberth Alexis Osorio O. >Professional Services Manager > > >Information Technologies de Colombia "INTEK" >Teléfono: (57-1)6206370 ext 15 >Fax: (57-1)6206365 >Celular: (57-315)3108457 >Santafé de Bogotá, D.C. Colombia >www.intek.com.co > >STORAGETEK >INFORMATION made POWERFUL > > > > > > -- -- jetez un oeil ici http://www.sensiva.com/ -- -- have a look here http://www.sensiva.com/ --

1 0

exportfs -u -a
by Robert Borowicz 21 May '03

21 May '03

Perhaps I'm rusty with my NFS knowledge.... I made a change to my /usr/local export. (-root on a build host) I did an "exportfs -u -a" and to my horror all of the *existing* /usr/local mounts went stale. I do not remember this happening with Auspex's (in a previous life) and SunOS 4.1.2. Perhaps I need to go back to the blue NFS/NIS O'Reilly book.... Is this a Solaris 2.8 ism, or am I missing something obvious in my re-entry to the world of NFS... Here is my vfstab entry: well:/vol/sysvol0/local - /usr/local nfs no yes bg,soft,intr TIA -Bob

2 1

Re: exportfs -u -a
by Robert Borowicz 21 May '03

21 May '03

I *KNOW* what the command does. I've read the man page and the book. HOWEVER, the way this used to work (and apparently not anymore) was you were free to unexport/unshare a dir/vol globally (IE: exportfs -u -a /usr/local) but it would *NOT* affect *EXISTING* mounts. Just newly requested ones. I'll go quietly now... -Bob At 11:16 AM 5/21/2003 -0500, you wrote: >man page says it all, dude! > >SunOS/BSD Compatibility Package Commands exportfs(1B) > >NAME > exportfs - translates exportfs options to share/unshare com- > mands > >SYNOPSIS > /usr/sbin/exportfs [ -aiuv ] [ -o options ] [ pathname ] > >DESCRIPTION > exportfs translates SunOS 4.x exportfs options to the > corresponding share/unshare options and invokes > share/unshare with the translated options. > > With no options or arguments, exportfs invokes share to > print out the list of all currently shared NFS filesystems. > > exportfs is the BSD/Compatibility Package command of > share(1M) and unshare(1M). Use share(1M)/ unshare(1M) when- > ever possible. > >OPTIONS > -a Invokes shareall(1M), or if -u is specified, invokes > unshareall(1M). > > -i Ignore options in /etc/dfs/dfstab. > > -u Invokes unshare(1M) on pathname. > > -v Verbose. > > -o options > Specify a comma-separated list of optional charac- > teristics for the filesystems being exported. exportfs > translates options to share-equivalent options. (see > share(1M) for information about individual options). > >ATTRIBUTES > See attributes(5) for descriptions of the following attri- > butes: > > ____________________________________________________________ > | ATTRIBUTE TYPE | ATTRIBUTE VALUE | > |_____________________________|_____________________________| > | Availability | SUNWcsu | > |_____________________________|_____________________________| > >SEE ALSO > share(1M), shareall(1M), unshare(1M), unshareall(1M), attri- > butes(5) > >SunOS 5.8 Last change: 28 Mar 1994 1 >Bob Bailey >Network Centric Systems (NCS) >North Texas Engineering Automation >Central Operations Desk >Phone: 972-952-2518 >Pager: 972-670-7336 >Alpha Pager: 9726707336(a)messaging.nextel.com > > >Robert Borowicz <rbaus(a)swbell.net> >Sent by: owner-toasters(a)mathworks.com > >05/21/2003 10:19 AM > > To: toasters(a)mathworks.com > cc: > Subject: exportfs -u -a > > >Perhaps I'm rusty with my NFS knowledge.... > >I made a change to my /usr/local export. (-root on a build host) I did an >"exportfs -u -a" and to my horror all of the *existing* /usr/local mounts >went stale. > >I do not remember this happening with Auspex's (in a previous life) and >SunOS 4.1.2. Perhaps I need to go back to the blue NFS/NIS O'Reilly book.... > >Is this a Solaris 2.8 ism, or am I missing something obvious in my re-entry >to the world of NFS... > >Here is my vfstab entry: > >well:/vol/sysvol0/local >- /usr/local nfs no yes bg,soft,intr > >TIA > >-Bob > >

1 0

RE: exportfs -u -a
by Robert Borowicz 21 May '03

21 May '03

I know that. But in the past it would simply fail to make any *new* mounts, not undo existing mounts.... At 08:40 AM 5/21/2003 -0700, Jason.Santos(a)pinnaclewest.com wrote: >It did exactly what you asked it to do: unexported (-u) all exports >(-a). >

1 0

RE: useradmin command
by Ehrhart, Rick 20 May '03

20 May '03

There is currently no way to limit admin users. See burt 42514. However you can restrict rsh and telnet access with: options.rsh.access and options.telnet.access. For example: options.telnet.access "host=admin_host". This will only allow telnet from the computer admin_host. Please check the man page for more details. - Rick - > -----Original Message----- > From: Robert Borowicz [mailto:rbaus@swbell.net] > Sent: Tuesday, May 20, 2003 7:49 AM > To: toasters(a)mathworks.com > Subject: useradmin command > > > I'm using the "useradmin" command to add users to my DOT > 6.3.1 for CIFS > authen since I don't have a DC. > > Unfortunately these users also become Filer Administrators > and I have to be > very careful not to let them onto the box. I'm looking at how > to handle > password administration for these users without letting them > have a telnet > session. Anybody use a "rsh" script to administers these user > accounts? > > Any ideas how I can limit them? The only thing I've come up > with is having > our manned Help Desk administer a telnet session for them > while the user is > physically in the Help Desk area. > > Ideas? > > -Bob > >

1 0

disk drive fails and netapp thinks there is an open in the FCAL l oop
by DFinn＠studentadvantage.com 20 May '03

20 May '03

This is the second time this has happened in the past week. I'm thinking there might actually be a hardware issue somewhere along the FCAL loop but does anyone else have any theories. from the message log: . . . Mon May 19 00:00:00 EDT [statd]: 12:00am up 2 days, 13:25 18869073 NFS ops, 4573028 CIFS ops, 0 HTTP ops Mon May 19 00:24:25 EDT [isp2100_timeout]: 1.1 (0xfffffc0000d83560,0x2a:00289370:0008,0/0,23228/0/0,58593/0): comman d timeout, quiescing drive. Mon May 19 00:24:29 EDT [isp2100_timeout]: 1.1: global device timer timeout, initiating device recovery. Mon May 19 00:24:29 EDT [isp2100_timeout]: Resetting device 1.1 . . ^ what happened here? . Tue May 20 02:46:55 EDT [isp2100_timeout]: 1.42 (0xfffffc0000d6ed20,0x28:00598770:0010,0/0,8363/0/0,56085/0): comman d timeout, quiescing drive. Tue May 20 02:46:58 EDT [isp2100_timeout]: 1.42: global device timer timeout, initiating device recovery. Tue May 20 02:46:58 EDT [isp2100_timeout]: Resetting device 1.42 Tue May 20 02:47:02 EDT [isp2100_timeout]: Resetting ISP2100 in slot 1 Tue May 20 02:47:22 EDT last message repeated 2 times Tue May 20 02:47:28 EDT [isp2100_timeout]: Loop recovery event generated by device 1.0. Tue May 20 02:47:33 EDT [isp2100_timeout]: Resetting ISP2100 in slot 1 Tue May 20 14:50:21 GMT [rc]: NIS: Group Caching has been enabled Tue May 20 10:50:22 EDT [rc]: e2a: Link up. Tue May 20 10:50:23 EDT [ses_admin]: No SCSI-3 Enclosure Services on host adapter 1 shelf 0. Tue May 20 10:50:23 EDT [ses_admin]: Check drive placement. . . . Tue May 20 10:50:28 EDT [rc]: relog syslog Tue May 20 02:47:53 EDT [isp2100_timeout]: Offlining loop attached to HBA in slot 1. Will try to reco Tue May 20 10:50:28 EDT [rc]: relog syslog Tue May 20 02:47:53 EDT [isp2100_timeout]: The fibre channel loop attache d to adapter 1 has gone down So I power off the netapp, power off all the disk shelves. Turn them back on, boot the netapp up and it comes up fine, both times same scenario. The previous time a disk had it's red LED lit up so it was easy to tell that it needed replacing. This did not happen this time. I pulled disk 1.42 because I thought it might have been the one causing problems and it's been replaced with a spare. Should I also pull disk 1.1? Thanks Dan One other strang thing. I can no longer log into Filer View. It prompts me for the password to the netapp, then once I enter the password it comes back with the following error : "Error communicating with host na4m-be msg=Connection refused: connect". Is the password for Filer View the same as the root password for the netapp. I am still able to telnet in. I tried disabling and enabling the httpd server and that didn't seem to help.

1 0

RE: sem-OT : rj45->db9 pin-out to connect to netapps console port
by DFinn＠studentadvantage.com 20 May '03

20 May '03

That's strange. I tried one of those and it didn't work. It's a black rj45->db9 connector labeled TERMINAL and it's the one I was using to attach to the serial port of a laptop to console into the cisco. I know the console port on the netapp works fine though because I can get into that with a serial cable and a laptop. -----Original Message----- From: Jason.Santos(a)pinnaclewest.com To: DFinn(a)studentadvantage.com Sent: 5/19/03 1:52 PM Subject: RE: sem-OT : rj45->db9 pin-out to connect to netapps console port They are pinned out the same as the adapters that came with the 2511 (labeled Terminal, I think). I have some at home, don't have one here, I can e-mail you later if you still didn't find it. -- Jason Santos Sr. Unix System Administrator APS/Pinnacle West Phoenix, AZ USA -----Original Message----- From: DFinn(a)studentadvantage.com [mailto:DFinn@studentadvantage.com] Sent: Monday, May 19, 2003 10:32 AM To: toasters(a)mathworks.com Subject: sem-OT : rj45->db9 pin-out to connect to netapps console port I've decided to try and use the Cisco 2511-RJ that we currently have in place for our sun gear and connect the netapps to that for network console connections. I picked up some rj45->db9 connectors that need to be pin'd out. Does anyone know how these are pin'd out offhand? Thanks Dan

2 1

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

1997

toasters