mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Xin Zhao" <uszhaoxin@gmail.com>
To: "Sunil Joshi" <mail2joshi@gmail.com>
Cc: linux-fsdevel <linux-fsdevel@vger.kernel.org>,
	linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: how do versioning filesystems take snapshot of opened files?
Date: Tue, 3 Jul 2007 01:44:52 -0400	[thread overview]
Message-ID: <4ae3c140707022244j67824c66g5da2d31d8fcfdc0e@mail.gmail.com> (raw)
In-Reply-To: <778391c50707022236v5157a933qea1994cf4cbce879@mail.gmail.com>

I do know how copy-on-write works. But this seems insufficient to
address the problem I asked.

One possible way is to modify the filesystem so that when a file is
opened for write, we always keep a copy of the file's metadata and a
CoW bitmap. For subsequent writes, we first copy the old data to
somewhere else in memory for backup, mark the CoW bitmap, and then
write to the file. The temporary data is discarded when the file is
closed. By checking the CoW bitmap, the backup application can
determine which data it should copy to the backup media.

This solution can address this problem. But it requires copy-on-write
on every write, no matter whether there is a backup operation. I
suspect that this solution will impact the system performance (at
least write performance) quite a bit and consume more memory.

Any further thought?

Thanks!


On 7/3/07, Sunil Joshi <mail2joshi@gmail.com> wrote:
> It depends how snapshot is being taken. Usually it is Copy On Write. Google
> for Copy on Write and you will find the answer for this.
>
>
>
>
> On 7/3/07, Xin Zhao <uszhaoxin@gmail.com> wrote:
> >
> > Hi,
> >
> >
> > If a file is already opened when snapshot command is issued,  the file
> > itself could be in an inconsistent state already. Before the file is
> > closed, maybe part of the file contains old data, the rest contains
> > new data.
> > How does a versioning filesystem guarantee that the file snapshot is
> > in a consistent state in this case?
> >
> > I googled it but didn't find any answer. Can someone explain it a little
> bit?
> >
> > Thanks
> > -
> > To unsubscribe from this list: send the line "unsubscribe linux-fsdevel"
> in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at
> http://vger.kernel.org/majordomo-info.html
> >
>
>

  parent reply	other threads:[~2007-07-03  5:45 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-07-03  5:28 Xin Zhao
     [not found] ` <778391c50707022236v5157a933qea1994cf4cbce879@mail.gmail.com>
2007-07-03  5:44   ` Xin Zhao [this message]
2007-07-03 13:09 ` Chris Mason
2007-07-03 16:12   ` Xin Zhao
2007-07-03 22:02   ` Neil Brown

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4ae3c140707022244j67824c66g5da2d31d8fcfdc0e@mail.gmail.com \
    --to=uszhaoxin@gmail.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mail2joshi@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®