Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Equivalent to VSS on Linux
1,864 views
Skip to first unread message
Quadibloc
Mar 27, 2013, 12:45:37 PM3/27/13
to
I've been looking for information on what Linux has that corresponds
to Microsoft's VSS.
One source says that LVM2 now has that functionality; another that a
commercial product, R1Soft HotCopy, provides this functionality. But I
don't think that either is quite what I'm thinking of.
What I see as a VSS equivalent in Linux would work something like
this:
At some point in time, applications would receive a SIGQUIET signal
from the operating system - just like they can receive SIGTERM or
SIGKILL signals at present.
Applications might register themselves in advance upon installation,
or identify their class when acknowledging the signal:
1) Dependent application - instead of just writing data directly to
the disk, saves data into a database program. Should have an option of
journaling in response to SIGQUIET in case the database program dies
first.
2) Normal application - writes its own data to the disk.
3) Host application - database programs and similar applications,
which save data for them, then write it to the disk. This way, they
can be asked to quiesce after the dependent applications, avoiding the
need to journal.
4) Invisible host application - stuff like an encrypted disk in a
file, that saves data for other applications which think they're just
writing to the disk directly and thus don't know they'll need to
journal.
VSS is likely to be protected by patents, of course, so this may delay
the ability to provide this kind of capability.
John Savard
to Microsoft's VSS.
One source says that LVM2 now has that functionality; another that a
commercial product, R1Soft HotCopy, provides this functionality. But I
don't think that either is quite what I'm thinking of.
What I see as a VSS equivalent in Linux would work something like
this:
At some point in time, applications would receive a SIGQUIET signal
from the operating system - just like they can receive SIGTERM or
SIGKILL signals at present.
Applications might register themselves in advance upon installation,
or identify their class when acknowledging the signal:
1) Dependent application - instead of just writing data directly to
the disk, saves data into a database program. Should have an option of
journaling in response to SIGQUIET in case the database program dies
first.
2) Normal application - writes its own data to the disk.
3) Host application - database programs and similar applications,
which save data for them, then write it to the disk. This way, they
can be asked to quiesce after the dependent applications, avoiding the
need to journal.
4) Invisible host application - stuff like an encrypted disk in a
file, that saves data for other applications which think they're just
writing to the disk directly and thus don't know they'll need to
journal.
VSS is likely to be protected by patents, of course, so this may delay
the ability to provide this kind of capability.
John Savard
Chris Davies
Mar 28, 2013, 9:43:36 AM3/28/13
to
Quadibloc <jsa...@ecn.ab.ca> wrote:
> I've been looking for information on what Linux has that corresponds
> to Microsoft's VSS.
> I've been looking for information on what Linux has that corresponds
> to Microsoft's VSS.
> What I see as a VSS equivalent in Linux would work something like
> this:
> this:
> 1) Dependent application - instead of just writing data directly to
> the disk, saves data into a database program. Should have an option of
> journaling in response to SIGQUIET in case the database program dies
> first.
How would the dependent application know that the database program wasn't
> the disk, saves data into a database program. Should have an option of
> journaling in response to SIGQUIET in case the database program dies
> first.
using the disk in question? Or does that become the database program's
problem?
Why would the application know that it was writing to disk A rather
than disk B? The C: and D: concept isn't as obvious in Unix/Linux-based
systems as everything's hung off a single root. (Yes, it's possible
to find out what partition you're writing to, but it's not something a
program typically would want - or need - to do.)
> 2) Normal application - writes its own data to the disk.
> 3) Host application - database programs and similar applications,
> which save data for them, then write it to the disk. This way, they
> can be asked to quiesce after the dependent applications, avoiding the
> need to journal.
pretending that it's written data to disk? Surely not.
LVM provides for snapshots, so applications can continue to write to
the disk oblivious of the fact that you've taken a snapshot are are busy
copying it (or whatever). Is this what you're looking for?
Chris
Richard Kettlewell
Mar 28, 2013, 11:52:32 AM3/28/13
to
Chris Davies <chris-...@roaima.co.uk> writes:
consistent filesystem state, much less provide the consistency
guarantees about application-level state that the OP is presumably
looking for. You need your application to expose an API through which
they can be told to quiesce to achieve that (or to design your
application so that there are no inconsistent states).
--
http://www.greenend.org.uk/rjk/
> Quadibloc <jsa...@ecn.ab.ca> wrote:
>> 2) Normal application - writes its own data to the disk.
>> 3) Host application - database programs and similar applications,
>> which save data for them, then write it to the disk. This way, they
>> can be asked to quiesce after the dependent applications, avoiding the
>> need to journal.
>
> An application that guarantees synchronous disk writes now has to start
> pretending that it's written data to disk? Surely not.
>
> LVM provides for snapshots, so applications can continue to write to
> the disk oblivious of the fact that you've taken a snapshot are are busy
> copying it (or whatever). Is this what you're looking for?
LVM just snapshots block devices. That can’t on its own guarantee a
>> 2) Normal application - writes its own data to the disk.
>> 3) Host application - database programs and similar applications,
>> which save data for them, then write it to the disk. This way, they
>> can be asked to quiesce after the dependent applications, avoiding the
>> need to journal.
>
> An application that guarantees synchronous disk writes now has to start
> pretending that it's written data to disk? Surely not.
>
> LVM provides for snapshots, so applications can continue to write to
> the disk oblivious of the fact that you've taken a snapshot are are busy
> copying it (or whatever). Is this what you're looking for?
consistent filesystem state, much less provide the consistency
guarantees about application-level state that the OP is presumably
looking for. You need your application to expose an API through which
they can be told to quiesce to achieve that (or to design your
application so that there are no inconsistent states).
--
http://www.greenend.org.uk/rjk/
Richard Kettlewell
Mar 28, 2013, 11:56:54 AM3/28/13
to
Quadibloc <jsa...@ecn.ab.ca> writes:
> I've been looking for information on what Linux has that corresponds
> to Microsoft's VSS.
>
> One source says that LVM2 now has that functionality; another that a
> commercial product, R1Soft HotCopy, provides this functionality. But I
> don't think that either is quite what I'm thinking of.
>
> What I see as a VSS equivalent in Linux would work something like
> this:
>
> At some point in time, applications would receive a SIGQUIET signal
> from the operating system - just like they can receive SIGTERM or
> SIGKILL signals at present.
FWIW I think signals are an atrocious way to perform IPC. They are
> I've been looking for information on what Linux has that corresponds
> to Microsoft's VSS.
>
> One source says that LVM2 now has that functionality; another that a
> commercial product, R1Soft HotCopy, provides this functionality. But I
> don't think that either is quite what I'm thinking of.
>
> What I see as a VSS equivalent in Linux would work something like
> this:
>
> At some point in time, applications would receive a SIGQUIET signal
> from the operating system - just like they can receive SIGTERM or
> SIGKILL signals at present.
difficult to recieve safely; they are difficult to send to the correct
recipient; they don’t allow for much information to be communicated to
the recipient; they can’t be sent across many privilege boundaries.
If you invent a VSS-workalike then please consider using some other
means of communication l-)
--
http://www.greenend.org.uk/rjk/
Aragorn
Mar 28, 2013, 12:14:48 PM3/28/13
to
On Thursday 28 March 2013 16:52, Richard Kettlewell conveyed the
following to comp.os.linux.misc...
Maybe a little hard to implement to the OP - given that we don't know
what filesystems he's using - but the XFS filesystem allows for
snapshots which include freezing of all I/O to and from the filesystem.
--
= Aragorn =
http://www.linuxcounter.net - registrant #223157
following to comp.os.linux.misc...
what filesystems he's using - but the XFS filesystem allows for
snapshots which include freezing of all I/O to and from the filesystem.
--
= Aragorn =
http://www.linuxcounter.net - registrant #223157
David Brown
Mar 28, 2013, 1:23:10 PM3/28/13
to
this freezing is synchronised with LVM snapshots. This means that if
you are using XFS or ext4 on the LVM, then your snapshots /are/ a
consistent filesystem (though not necessarily consistent on the
application - but "serious" applications like databases have journalling
anyway and will work fine with such snapshoting).
Another alternative is btrfs for the filesystem.
Quadibloc
Mar 28, 2013, 4:59:21 PM3/28/13
to
On Mar 28, 7:43 am, Chris Davies <chris-use...@roaima.co.uk> wrote:
> An application that guarantees synchronous disk writes now has to start
> pretending that it's written data to disk? Surely not.
Hmm. A database application stores data for other programs that use
> An application that guarantees synchronous disk writes now has to start
> pretending that it's written data to disk? Surely not.
it. Once it's been advised to quiesce, it can write everything to disk
that's currently in progress, but after it says it's successfully
quiesced, it will have to turn down requests. It can't even journal at
that point, since it has lost disk access until it's told that the
part of the disk it's using has been saved.
It can't pretend by keeping things in memory either; there's no
guarantee the shadowing will be fast enough.
So its customers have to be able to respond to a "no" from the
database program with journaling, and they should respond to a request
to quiesce by anticipating that they might get a "no".
John Savard
Quadibloc
Mar 28, 2013, 5:01:19 PM3/28/13
to
On Mar 28, 9:56 am, Richard Kettlewell <r...@greenend.org.uk> wrote:
> If you invent a VSS-workalike then please consider using some other
> means of communication l-)
I know that some database applications allow themselves to be run like
> If you invent a VSS-workalike then please consider using some other
> means of communication l-)
this
database_app -quiesce
and some backup applications can talk to databases that way if it's
set up by hand.
I was just thinking of building quiescence into the OS at a very basic
level, treating it as if it had been around from the start, rather
than some exotic new thing tacked on.
John Savard
Whiskers
Mar 28, 2013, 9:37:01 PM3/28/13
to
On 2013-03-27, Quadibloc <jsa...@ecn.ab.ca> wrote:
> I've been looking for information on what Linux has that corresponds
> to Microsoft's VSS.
>
> One source says that LVM2 now has that functionality; another that a
> commercial product, R1Soft HotCopy, provides this functionality. But I
> don't think that either is quite what I'm thinking of.
Wikipedia is good for clues when questions are framed badly:
> I've been looking for information on what Linux has that corresponds
> to Microsoft's VSS.
>
> One source says that LVM2 now has that functionality; another that a
> commercial product, R1Soft HotCopy, provides this functionality. But I
> don't think that either is quite what I'm thinking of.
Microsoft Visual SourceSafe (VSS) is a source control software package
oriented towards small software development projects. Like most source
control systems, SourceSafe creates a virtual library of computer files.
While most commonly used for source code, SourceSafe can actually handle
any type of file in its database, but prior versions have been shown
to be unstable when confronted with large amounts of non-textual data
(images, binary executables, etc.). [...]
<https://en.wikipedia.org/wiki/Visual_SourceSafe>.
So now we know that "VSS" is a "Revision Control System". There are a fair
few of those, mostly not restricted to Windows only and not in a state of
"serious bug fixes only". Wikipedia provides a list (which may not be
accurate or complete, of course)
<https://en.wikipedia.org/wiki/Comparison_of_revision_control_software>
> What I see as a VSS equivalent in Linux would work something like
> this:
>
> At some point in time, applications would receive a SIGQUIET signal
> from the operating system - just like they can receive SIGTERM or
> SIGKILL signals at present.
>
> Applications might register themselves in advance upon installation,
> or identify their class when acknowledging the signal:
>
> 1) Dependent application - instead of just writing data directly to
> the disk, saves data into a database program. Should have an option of
> journaling in response to SIGQUIET in case the database program dies
> first.
> 2) Normal application - writes its own data to the disk.
> 3) Host application - database programs and similar applications,
> which save data for them, then write it to the disk. This way, they
> can be asked to quiesce after the dependent applications, avoiding the
> need to journal.
> 4) Invisible host application - stuff like an encrypted disk in a
> file, that saves data for other applications which think they're just
> writing to the disk directly and thus don't know they'll need to
> journal.
>
> VSS is likely to be protected by patents, of course, so this may delay
> the ability to provide this kind of capability.
>
> John Savard
you're looking for a "back-up strategy". Linux has plenty of tools for
that, starting with journalled file systems, managed volumes that can
handle 'snapshots' (ie LVM), rsync, cron, bash scripts, and even high level
backup tools with graphical user interfaces, eg 'Webmin'.
--
-- ^^^^^^^^^^
-- Whiskers
-- ~~~~~~~~~~
Richard Kettlewell
Mar 29, 2013, 4:55:51 AM3/29/13
to
Whiskers <catwh...@operamail.com> writes:
> Quadibloc <jsa...@ecn.ab.ca> wrote:
>> I've been looking for information on what Linux has that corresponds
>> to Microsoft's VSS.
>>
>> One source says that LVM2 now has that functionality; another that a
>> commercial product, R1Soft HotCopy, provides this functionality. But I
>> don't think that either is quite what I'm thinking of.
>
> Wikipedia is good for clues when questions are framed badly:
>
> Microsoft Visual SourceSafe (VSS) is a source control software package
> oriented towards small software development projects. Like most source
> control systems, SourceSafe creates a virtual library of computer files.
> While most commonly used for source code, SourceSafe can actually handle
> any type of file in its database, but prior versions have been shown
> to be unstable when confronted with large amounts of non-textual data
> (images, binary executables, etc.). [...]
>
> <https://en.wikipedia.org/wiki/Visual_SourceSafe>.
Wrong VSS. He’s talking about
> Quadibloc <jsa...@ecn.ab.ca> wrote:
>> I've been looking for information on what Linux has that corresponds
>> to Microsoft's VSS.
>>
>> One source says that LVM2 now has that functionality; another that a
>> commercial product, R1Soft HotCopy, provides this functionality. But I
>> don't think that either is quite what I'm thinking of.
>
> Wikipedia is good for clues when questions are framed badly:
>
> Microsoft Visual SourceSafe (VSS) is a source control software package
> oriented towards small software development projects. Like most source
> control systems, SourceSafe creates a virtual library of computer files.
> While most commonly used for source code, SourceSafe can actually handle
> any type of file in its database, but prior versions have been shown
> to be unstable when confronted with large amounts of non-textual data
> (images, binary executables, etc.). [...]
>
> <https://en.wikipedia.org/wiki/Visual_SourceSafe>.
http://msdn.microsoft.com/en-gb/library/windows/desktop/bb968832(v=vs.85).aspx
--
http://www.greenend.org.uk/rjk/
Chris Davies
Mar 29, 2013, 9:51:24 AM3/29/13
to
Richard Kettlewell <r...@greenend.org.uk> wrote:
> LVM just snapshots block devices. That can’t on its own guarantee a
> consistent filesystem state, much less provide the consistency
> guarantees about application-level state that the OP is presumably
> looking for.
Yes. I'm aware of that. I had hoped my questions would draw out further
> LVM just snapshots block devices. That can’t on its own guarantee a
> consistent filesystem state, much less provide the consistency
> guarantees about application-level state that the OP is presumably
> looking for.
information from the OP.
Chris
Whiskers
Mar 29, 2013, 5:47:57 PM3/29/13
to
Quadibloc
Mar 30, 2013, 3:03:34 AM3/30/13
to
On Mar 28, 9:52 am, Richard Kettlewell <r...@greenend.org.uk> wrote:
> You need your application to expose an API through which
> they can be told to quiesce to achieve that (or to design your
> application so that there are no inconsistent states).
Yes. And for every important application to expose such an API, or,
> You need your application to expose an API through which
> they can be told to quiesce to achieve that (or to design your
> application so that there are no inconsistent states).
rather, to follow an API exposed by, say, LVM, there has to be one
"official", or at least most popular, mechanism that uses the API.
John Savard
Quadibloc
Mar 30, 2013, 3:05:21 AM3/30/13
to
On Mar 28, 7:37 pm, Whiskers <catwhee...@operamail.com> wrote:
> Microsoft Visual SourceSafe (VSS) is a source control software package
So it is, but I'm talking about Microsoft Volume Shadow Copy Service.
> Microsoft Visual SourceSafe (VSS) is a source control software package
It's unfortunate they gave it the same acronym.
John Savard
David Brown
Mar 30, 2013, 7:53:28 AM3/30/13
to
"SourceSafe" ever existed...
Mladen Gogala
Mar 30, 2013, 12:17:05 PM3/30/13
to
snapshots, so can BRTFS and ZFS.
--
http://mgogala.byethost5.com
Quadibloc
Apr 4, 2013, 12:25:24 PM4/4/13
to
On Mar 30, 5:53 am, David Brown <david.br...@removethis.hesbynett.no>
wrote:
> They are probably hoping that everyone will forget that Visual
> "SourceSafe" ever existed...
Well, it is confusing, since the current tool for that purpose from
Microsoft is Microsoft Visual Studio Team Foundation Server.
John Savard
wrote:
> They are probably hoping that everyone will forget that Visual
> "SourceSafe" ever existed...
Microsoft is Microsoft Visual Studio Team Foundation Server.
John Savard
David Brown
Apr 4, 2013, 4:48:05 PM4/4/13
to
"Team Foundation Server" - if you store code in Foundation Server, there
is a fairly good chance you'll be able to get it out again in one piece.
With "SourceSafe", Microsoft recommends you do a full database
maintenance run once a week to limit the spread of corrupt checkins -
and they have never allowed Microsoft employees to use it for their own
code, because it is too unreliable!
0 new messages