Mingming Cao wrote:
On Tue, 2007-07-03 at 15:58 +0530, Kalpak Shah wrote:
On Sun, 2007-07-01 at 03:36 -0400, Mingming Cao wrote:
+
+#define EXT4_INODE_GET_XTIME(xtime, inode, raw_inode) \
+do { \
On Tue, 2007-07-03 at 15:58 +0530, Kalpak Shah wrote:
> On Sun, 2007-07-01 at 03:36 -0400, Mingming Cao wrote:
> > +
> > +#define EXT4_INODE_GET_XTIME(xtime, inode, raw_inode)
> >\
> > +do {
> >
Amit K. Arora wrote:
FA_FL_NO_MTIME 0x10 /* keep same mtime (default change on size, data change) */
FA_FL_NO_CTIME 0x20 /* keep same ctime (default change on size, data change) */
NACK to these aswell. If i_size changes c/mtime need updates, if the size
doesn't chamge they don't. No need to
I'd like to reference a paper titled "FASS : A Flash-Aware Swap System".
(http://kernel.kaist.ac.kr/~jinsoo/publication/iwssps05.pdf)
The paper describes a technique that uses NAND flash as a swap device
without FTL (Flash Translation Layer) or filesystem.
It is not related with XIP, however.
O
On Jul 03, 2007 18:15 -0400, J. Bruce Fields wrote:
> How will nfsd tell whether it can really on a given filesystem's
> i_version, or whether it should fall back on ctime?
Good question.
> > As to performance concerns that raise before the inode version counter
> > (at least for ext4) is done i
Linus, Andrew, please apply the bug fix patch at the end of this reply
for .22.
> >>One of our perf. team ran into this while doing some runs.
> >>I didn't see anything obvious - it looks like we converted
> >>async IO to synchronous one. I didn't spend much time digging
> >>around.
OK, I think t
On Sat, Jun 30, 2007 at 10:20:13AM +0100, Christoph Hellwig wrote:
> On Fri, Jun 29, 2007 at 03:21:25PM -0400, J. Bruce Fields wrote:
> > From: J. Bruce Fields <[EMAIL PROTECTED]>
> >
> > Share more code between setlease (used by nfsd) and fcntl.
> >
> > Also some minor cleanup.
>
> Looks good.
On Mon, Jul 02, 2007 at 10:58:33AM -0400, Mingming Cao wrote:
> Trond or Bruce, can you please review these patch series and ack if you
> agrees?
Thanks, looks like what we need!
How will nfsd tell whether it can really on a given filesystem's
i_version, or whether it should fall back on ctime?
The first util-linux-ng 2.13 release candidate is available at
ftp://ftp.kernel.org/pub/linux/utils/util-linux-ng/v2.13/
Thanks to all who help with util-linux resuscitation:
H. Peter Anvin
Ian Kent
and contribute to this project:
Arkadiusz Miskiewicz Matthias Koeni
On Tuesday July 3, [EMAIL PROTECTED] wrote:
>
> Getting a snapshot that is useful with respect to application data
> requires help from the application.
Certainly.
> The app needs to be shutdown or
> paused prior to the snapshot and then started up again afte
On Jul 03, 2007 10:24 -0400, Trond Myklebust wrote:
> It looks OK to me, but you might want to strip out the now redundant
> i_version updates in add_dirent_to_buf(), ext4_rmdir(), ext4_rename().
Agreed, and I thought we discussed that already on the ext4 list.
> I also have some questions about
On Jul 03, 2007 12:19 +0530, Aneesh Kumar K.V wrote:
> Mingming Cao wrote:
> >Index: linux-2.6.22-rc4/fs/ext4/super.c
> >===
> >--- linux-2.6.22-rc4.orig/fs/ext4/super.c2007-06-13
> >17:19:11.0 -0700
> >+++ linux-2.6.22-r
On Sun, Jul 01, 2007 at 03:37:16AM -0400, Mingming Cao wrote:
> This patch adds a 32-bit i_version_hi field to ext4_inode, which can be used
> for 64-bit inode versions. This field will store the higher 32 bits of the
> version, while Jean Noel's patch has added support to store the lower 32-bits
On 7/3/07, Bryan Henderson <[EMAIL PROTECTED]> wrote:
>>we want a open/close consistency in snapshots.
>
>This depends on the transaction engine in your filesystem. None of the
>existing linux filesystems have a way to start a transaction when the
>file opens and finish it when the file closes,
>>we want a open/close consistency in snapshots.
>
>This depends on the transaction engine in your filesystem. None of the
>existing linux filesystems have a way to start a transaction when the
>file opens and finish it when the file closes, or a way to roll back
>individual operations that have h
On Tue, 3 Jul 2007 13:15:06 -0400
"Xin Zhao" <[EMAIL PROTECTED]> wrote:
> OK. From discussion above, can we reach a conclusion: from the
> application perspective, it is very hard, if not impossible, to take a
> transactional consistent snapshot without the help from applications?
You definitely
OK. From discussion above, can we reach a conclusion: from the
application perspective, it is very hard, if not impossible, to take a
transactional consistent snapshot without the help from applications?
Chris, you mentioned that "Many different applications support some
form of pausing in order
On Tue, 3 Jul 2007 12:31:49 -0400
"Xin Zhao" <[EMAIL PROTECTED]> wrote:
> That's a good point!
>
> But this sounds hopeless to take a real consistent snapshot from app
> perspective unless you shutdown the computer. Right?
Many different applications support some form of pausing in order
to faci
>But you look around, you may find that many
>systems claim that they can take snapshot without shutdown the
>application.
The claim is true, because you can just pause the application and not shut
it down. While this means you can't simply add snapshot capability and
solve your copy consistenc
On Monday 02 July 2007 22:15, Christoph Hellwig wrote:
> AA on the other hand just fucks up VFS layering [...]
Oh come on, this claim clearly isn't justified. How on earth is passing
vfsmounts down the lsm hooks supposed to break vfs layering? We are not
proposing to pass additional information
That's a good point!
But this sounds hopeless to take a real consistent snapshot from app
perspective unless you shutdown the computer. Right?
Thanks.
On 7/3/07, Bryan Henderson <[EMAIL PROTECTED]> wrote:
> Consistent state means many different things.
And, significantly, open/close has noth
> Consistent state means many different things.
And, significantly, open/close has nothing to do with any of them
(assuming we're talking about the system calls). open/close does not
identify a transaction; a program may open and close a file multiple times
the course of making a "single" upd
Thanks for your reply.
Sounds like one has to stop or pause the applications to get
consistent snapshot? But you look around, you may find that many
systems claim that they can take snapshot without shutdown the
application. Actually, I think it is impractical to require that app
to be shutdown
On Mon, 2007-07-02 at 10:58 -0400, Mingming Cao wrote:
> Trond or Bruce, can you please review these patch series and ack if you
> agrees? Thanks.
>
> As to performance concerns that raise before the inode version counter
> (at least for ext4) is done inside ext4_mark_inode_dirty), so there is
> n
On Mon, 2 July 2007 17:46:40 -0700, Jared Hulbert wrote:
>
> Right, the solution to swap problem is identical to the rw XIP
> filesystem problem.Jörn, that's why you're the self-appointed
> subject matter expert!
All right. I'll try to make an important face whenever the subject
comes up.
N
On Tue, 3 Jul 2007 01:28:57 -0400
"Xin Zhao" <[EMAIL PROTECTED]> 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
On Tue, Jul 03, 2007 at 11:31:07AM +0100, Christoph Hellwig wrote:
> On Tue, Jul 03, 2007 at 03:38:48PM +0530, Amit K. Arora wrote:
> > > FA_FL_DEALLOC 0x01 /* deallocate unwritten extent (default
> > > allocate) */
> > > FA_FL_KEEP_SIZE 0x02 /* keep size for EOF {pre,de}alloc (defau
On Sun, 2007-07-01 at 03:36 -0400, Mingming Cao wrote:
> +
> +#define EXT4_INODE_GET_XTIME(xtime, inode, raw_inode)
>\
> +do {\
> + (inode)->xtime.tv_sec = le32_to_cpu((raw_inode)->xtime);
On Sun, 2007-07-01 at 03:36 -0400, Mingming Cao wrote:
> +
> +#define EXT4_INODE_GET_XTIME(xtime, inode, raw_inode)
>\
> +do {\
> + (inode)->xtime.tv_sec = le32_to_cpu((raw_inode)->xtime);
On Tue, Jul 03, 2007 at 03:38:48PM +0530, Amit K. Arora wrote:
> > FA_FL_DEALLOC 0x01 /* deallocate unwritten extent (default
> > allocate) */
> > FA_FL_KEEP_SIZE 0x02 /* keep size for EOF {pre,de}alloc (default change
> > size) */
> > FA_FL_DEL_DATA 0x04 /* delete existing
On Sat, Jun 30, 2007 at 12:52:46PM -0400, Andreas Dilger wrote:
> The @mode flags that are currently under consideration are (AFAIK):
>
> FA_FL_DEALLOC 0x01 /* deallocate unwritten extent (default allocate)
> */
> FA_FL_KEEP_SIZE 0x02 /* keep size for EOF {pre,de}alloc (default chan
31 matches
Mail list logo
