toasters November 1998

toasters@lists.teaparty.net

55 participants
70 discussions

Re: hard link .snapshot files
by mds＠ns.gbnet.net 06 Nov '98

06 Nov '98

Actually this issue - of wanting to bring files from a snapshot back into the current filesystem, without raising the occupancy of the disks any more - is something that has crossed my mind before. There are times, for example, when it'd be nice to just bring back a large directory-tree into current use from a snapshot, perhaps/probably toasting anything in the current filesystem image that would name-clash but not having to freshly copy the data into new free blocks on the filer - perhaps because you are close to filling the filer already. Now if it's the total contents of the filer in question then you could take the filer down and use the requisite admin commands (perhaps with the help of the NetApp support folk) to use an older snapshot as your current filesystem image. 'Rolling back to a named consistency point' would be something akin to the NetApp way of putting it. However, I've often thought it'd be darned useful to say: 'take everything from this directory down from that snapshot and graft it coherently into place in the current filesystem here, but leave everything else as it is currently'. This is probably a great deal to ask and couldn't be done with normal filesystem operations, CIFS/NFS notwithstanding. However, as an option available to an admin I think it would be stunningly useful to some folk. This would take some cunning WAFL wizardry to accomplish I think, but it's not beyond the bounds of credibility. > As I'm sure you've already discovered, you can't create a hard link to a > file in a snapshot. The reason is that snapshots are read-only, but it is > necessary to increment the number of links in the linked-to inode. You can > use a symbolic link, of course, but it would point to whatever was at that > location. To prevent the snapshot from being recycled, you could do a "snap > rename" of hourly.0 or whatever to something else. > > Mark > > -----Original Message----- > From: Jim Harm <harm1(a)llnl.gov> > To: toasters(a)mathworks.com <toasters(a)mathworks.com> > Date: Thursday, November 05, 1998 8:56 AM > Subject: hard link .snapshot files > > > >We have the need to occasionally recover a LARGE file and we would like to > >recover it quickly without making the massive increase in space usage that > >would result if we merely copied the file from .snapshot to the old > directory. > > > >Can we build a hard link from the old directory to the > >.snapshot/hourly.#/Large.file and how will that be protected with the next > >snapshot? > > > >I don't want to screw anything up. Our users ARE rocket scientists. > > > >}}}===============>> LLNL > >James E. Harm (Jim); jharm(a)llnl.gov > >(925) 422-4018 Page: 423-7705x57152 > > > > > > >

2 1

FW: ndmpcopy port for HP/UX
by Melvin, Grant 06 Nov '98

06 Nov '98

Hi, NDMPcopy for HP-UX clients available on NOW: http://now.netapp.com/tools/ [index pages] http://now.netapp.com/download/tools/ndmpcopy/ [tool page] [Thanks to Paul Albers & Doug Mendoza] Cheers, Grant

1 0

Re: hard link .snapshot files
by Mark Muhlestein 05 Nov '98

05 Nov '98

As I'm sure you've already discovered, you can't create a hard link to a file in a snapshot. The reason is that snapshots are read-only, but it is necessary to increment the number of links in the linked-to inode. You can use a symbolic link, of course, but it would point to whatever was at that location. To prevent the snapshot from being recycled, you could do a "snap rename" of hourly.0 or whatever to something else. Mark -----Original Message----- From: Jim Harm <harm1(a)llnl.gov> To: toasters(a)mathworks.com <toasters(a)mathworks.com> Date: Thursday, November 05, 1998 8:56 AM Subject: hard link .snapshot files >We have the need to occasionally recover a LARGE file and we would like to >recover it quickly without making the massive increase in space usage that >would result if we merely copied the file from .snapshot to the old directory. > >Can we build a hard link from the old directory to the >.snapshot/hourly.#/Large.file and how will that be protected with the next >snapshot? > >I don't want to screw anything up. Our users ARE rocket scientists. > >}}}===============>> LLNL >James E. Harm (Jim); jharm(a)llnl.gov >(925) 422-4018 Page: 423-7705x57152 > > >

2 1

Re: can't see ~snapshot directory
by Tom Reingold 05 Nov '98

05 Nov '98

On Thu, 05 Nov 1998 08:01:57 CST, David Drum <david(a)more.net> wrote: > I find it disgusting that NetApp caters to Microsoft's ineptitude. Let's be fair. snapshots are strange. They are links to files, but they appear to be duplicates. We had to provide our unix users with a new "du" command so it wouldn't traverse snapshots. How could Microsoft have foreseen this problem and written their apps accordingly? -- Tom Reingold tommy(a)bell-labs.com http://www.bell-labs.com/~tommy The problem with this world is that there's too much apathy. But I don't really care.

6 7

Re: can't see ~snapshot directory
by Tom Reingold 05 Nov '98

05 Nov '98

On Thu, 05 Nov 1998 11:05:26 PST, "Chad H. Tudor" <chtudor(a)stanford.edu> wrote: > : find . -name .snapshot -prune -o -print > > While this is really helpful; the find would not be for me, as I do > understand how find operates and more importantly I understand the command > man 'splat'. What I do have is a shop full of folks who do not and it > would be easier if I could point them to a specific biniary. I betcha it would be trivial to take the source code for gnu find and put in a rule never to traverse a directory by a given name. -- Tom Reingold tommy(a)bell-labs.com http://www.bell-labs.com/~tommy Bell Labs, the Research and Development unit of Lucent Technologies Murray Hill, NJ, 07974-0636 US

1 0

Re: can't see ~snapshot directory
by Tom Reingold 05 Nov '98

05 Nov '98

On Thu, 05 Nov 1998 09:54:20 PST, "Chad H. Tudor" <chtudor(a)stanford.edu> wrote: > :Let's be fair. snapshots are strange. They are links to files, but > :they appear to be duplicates. We had to provide our unix users with > :a new "du" command so it wouldn't traverse snapshots. > > This raises another question. > > Would there be a find laying about that ignores same? find . -name .snapshot -prune -o -print

2 1

Re: can't see ~snapshot directory
by David Drum 05 Nov '98

05 Nov '98

Quoth Mark Muhlestein: > Huh? This change only affects CIFS clients. *ouch* I guess I missed that in the original poster's email. Sorry. Regards, David K. Drum david(a)more.net -- It's hard to be bored when you're as stupid as a line. [1] Reality has a tendency to be so uncomfortably real. [2] When you proceed deliberately, mistakes don't cascade, they instruct. [3] What you notice becomes your life. [4] [1] Vernor Vinge [2] Neil Peart [3] Stewart Brand [4] Michael Chitwood

1 0

Re: can't see ~snapshot directory
by Tom Reingold 05 Nov '98

05 Nov '98

On Thu, 05 Nov 1998 11:21:38 CST, David Drum <david(a)more.net> wrote: > I will admit that file system theory is not that different from UNIX > to PC. Therefore you are correct. My question then is: Why is this > only a problem now? How were UNIX users able to manage with one default > behavior all this time? Why can't the CIFS users just RTFM and configure > the NetApp so that it works the way they need? NetApp is thumbing its > nose at the installed base of (UNIX) users, who will now have to restore > the old default configuration. Just my Microsoft rant of the day. We mount each user's home directory as /home/whatever, so it does actually cause a problem (with things such as du). That is to say it's a problem for both PC and UNIX users. You could argue that the solution should be on the client side, but until that comes, it's nice that the server offers us an option. But you can't argue that Windows is more broken than UNIX in this case.

1 0

Re: Dual home fiber
by Gilbert Smith 05 Nov '98

05 Nov '98

At 10:13 AM 11/5/98 +0000, Algar, Christopher [PAI01:8881:EXCH] wrote: >Greetings. > >I'm having a bit of difficulty configuring a F760 with two fiber cards on >different sub nets. >It's been running fine with ifconfig f3 `hostname`-f3 netmask 255.255.240.0 >I've tried adding a similar line to etc/rc for f1 explicitly stating the IP >address instead of hostname, installing the additional card in slot 1 and >rebooting. Also tried installing the card with no changes to rc and >rebooting. >The result is the same, the system panics and fails to boot. > >Can anyone help? I would try floppy boot using option (no /etc/rc, I think #2 from the menu). Then run command, "sysconfig -v" and examine the output. Do you see both cards listed in the sysconfig output and are the two cards identical? Now run command "setup" and answer the questions. Setup will keep a backup copy of all your /etc/?? config files like (/etc/rc, /etc/exports, /etc/hosts, etc.). But setup should choose the appropriate mediatype and build the correct rc file for your hardware. There is a mediatype argument to the ifconfig command. The panic messge you receive might help. Hope this helps, Gil

1 0

Re: can't see ~snapshot directory
by sirbruce＠ix.netcom.com 05 Nov '98

05 Nov '98

On 11/05/98 11:39:35 you wrote: > > >On Thu, 05 Nov 1998 08:01:57 CST, > David Drum <david(a)more.net> wrote: > >> I find it disgusting that NetApp caters to Microsoft's ineptitude. > >Let's be fair. snapshots are strange. They are links to files, but >they appear to be duplicates. We had to provide our unix users with >a new "du" command so it wouldn't traverse snapshots. > >How could Microsoft have foreseen this problem and written their apps >accordingly? The real problem, IMHO, is that the snapshots should be treated as their own seperate partition, and be mounted as such, rather than inserting .snapshot directories. Of course, this does make it a little more difficult to explain to the user where to go to get their files, and with NFS it necessitates lots of new mounts. You could just turn the snaps off and mount it seperately and test this yourself; I think it will work. It also avoids the problem of copying the old file over it's newer copy with the same inode (in UNIX). Bruce

1 0

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 November 1998