Date: Thu, 22 Feb 2007 13:26:57 -0800 (PST) From: Shane Adams <adamsch1@yahoo.com> To: freebsd-fs@FreeBSD.ORG Subject: Re: Advice on runtime directories ala .snapshot Message-ID: <320631.20440.qm@web31815.mail.mud.yahoo.com>
next in thread | raw e-mail | index | archive | help
Sorry I wasn't clear earlier. I'd like to emulate how netapp drops a .snap=
shot directory in any subdirectory of a snapshotted filesystem.=0A=0AIt see=
med natural to do this dynamically on a per-request basis. =0A=0AAfter rea=
ding your response I happened upon nullfs, and I'm now thinking that would =
be the right area to look at? At *least* for simplicity?=0A=0AScrewing aro=
und on a netapp I found all .snapshot directory entries had the same ino, w=
hile subdirectories, like nightly_0, nightly_1 etc. had seemingly unique in=
o's, which would indicate to me they are persisting them somehow, or not, a=
nd they cache them as long as possible/necessary.=0A=0AShane=0A=0A----- Ori=
ginal Message ----=0AFrom: Oliver Fromme <olli@lurza.secnetix.de>=0ATo: fre=
ebsd-fs@FreeBSD.ORG; adamsch1@yahoo.com=0ASent: Sunday, February 18, 2007 1=
1:53:53 PM=0ASubject: Re: Advice on runtime directories ala .snapshot=0A=0A=
Shane Adams wrote:=0A > I've been thinking about how I could add a "virtual=
" directory entry=0A > similar to netapp, namely a .snapshot. Obviously I'=
d want to do this=0A > at runtime, but I'm having trouble attacking this pr=
oblem.=0A=0AThere's no precedent for such a thing in FreeBSD currently.=0AT=
he closest thing would be the ".snap" directory used for=0AFreeBSD's snapsh=
ot feature, or maybe even the historical=0A"lost+found" directory. But bot=
h of them are created=0Astatically in the file system, and they represent o=
rdinary=0Adirectory entries without any magic.=0A=0AYou will find purely sy=
nthetic files and directories only=0Ain the synthetic file systems such as =
procfs or devfs.=0A=0A > I've been looking at the ufs_lookup routines, seem=
s thats the only=0A > place to tackle such a feature? Or possibly inject a=
.snapshot entry=0A > as the last entry read in a call to ufs_readdir ?=0A=
=0AIt would be easier to give advice if we knew what you're=0Aactually tryi=
ng to implement. Personally, I think it's not=0Aa good idea to mix real an=
d synthetic entries within the=0Asame file system. Or at least there shoul=
d be _very_ good=0Areasons for doing so, and very careful consideration of =
all=0Apossible cases. For example, what's supposed to happen in=0Acase of =
a conflict, i.e. if there is already a real entry=0Awith the same name (".s=
napshot") with some contents?=0A=0A > I believe doing a ls -la on a netapp =
will not return the .snapshot=0A > directory, only explicitly nameing the d=
irectory will achieve the=0A > effects you want.=0A=0AThat behaviour is con=
figurable. On a NetApp filer you can=0Aconfigure per volume whether the .s=
napshot directory=0Aappears only in the mount point directory, or in every=
=0Adirectory below it. In the case of a NetApp it's not a big=0Aproblem to=
manage such synthetic directories, because it=0Ahas full controll over its=
file system. Clients can only=0Aaccess it remotely (NFS, SMB, ...), so fr=
om the clients'=0Aviewpoint the whole file system is kind of "synthetic".=
=0A=0ABest regards=0A Oliver=0A=0A-- =0AOliver Fromme, secnetix GmbH & Co=
. KG, Marktplatz 29, 85567 Grafing b. M.=0AHandelsregister: Registergericht=
Muenchen, HRA 74606, Gesch=E4ftsfuehrung:=0Asecnetix Verwaltungsgesellsch=
. mbH, Handelsregister: Registergericht M=FCn-=0Achen, HRB 125758, Gesch=
=E4ftsf=FChrer: Maik Bachmann, Olaf Erb, Ralf Gebhart=0AAny opinions expres=
sed in this message are personal to the author and may=0Anot necessarily re=
flect the opinions of secnetix GmbH & Co KG in any way.=0AFreeBSD-Dienstlei=
stungen, -Produkte und mehr: http://www.secnetix.de/bsd=0A=0A"If you think=
C++ is not overly complicated, just what is a protected=0Aabstract virtual=
base pure virtual private destructor, and when was the=0Alast time you nee=
ded one?"=0A -- Tom Cargil, C++ Journal=0A=0A=0A
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?320631.20440.qm>