On Sat, Jan 26, 2008 at 04:35:26PM +1100, David Chinner wrote:
> On Fri, Jan 25, 2008 at 07:59:38PM +0900, Takashi Sato wrote:
> > The points of the implementation are followings.
> > - Add calls of the freeze function (freeze_bdev) and
> > the unfreeze function (thaw_bdev) in ext3_ioctl().
> >
On Fri, Jan 25, 2008 at 07:59:38PM +0900, Takashi Sato wrote:
> The points of the implementation are followings.
> - Add calls of the freeze function (freeze_bdev) and
> the unfreeze function (thaw_bdev) in ext3_ioctl().
>
> - ext3_freeze_timeout() which calls the unfreeze function (thaw_bdev)
>
On Fri, Jan 25, 2008 at 09:42:30PM +0900, Takashi Sato wrote:
> >I am also wondering whether we should have system call(s) for these:
> >
> >On Jan 25, 2008 12:59 PM, Takashi Sato <[EMAIL PROTECTED]> wrote:
> >>+ case EXT3_IOC_FREEZE: {
> >
> >>+ case EXT3_IOC_THAW: {
> >
> >And just co
On Thu, Jan 24, 2008 at 11:25:32AM +0530, Aneesh Kumar K.V wrote:
> +static int free_ext_idx(handle_t *handle, struct inode *inode,
> + struct ext4_extent_idx *ix)
> +{
> + int i, retval = 0;
> + ext4_fsblk_t block;
> + struct buffer_head *bh;
> +
>> Incidentally, some context for the AIX approach to the OOM problem: a
>> process may exclude itself from OOM vulnerability altogether. It
places
>> itself in "early allocation" mode, which means at the time it creates
>> virtual memory, it reserves enough backing store for the worst case.
On Fri, 2008-01-25 at 04:09 -0700, Andreas Dilger wrote:
> On Jan 24, 2008 17:25 -0700, Zan Lynx wrote:
> > Have y'all been following the /dev/mem_notify patches?
> > http://article.gmane.org/gmane.linux.kernel/628653
>
> Having the notification be via poll() is a very restrictive processing
> m
On Fri, 25 Jan 2008, Bryan Henderson wrote:
> > AIX basically did this with SIGDANGER (the signal is ignored by
> > default), except there wasn't the ability for the process to tell the
> > kernel at what level of memory pressure before it should start getting
> > notified, and there was no way fo
On Jan 25, 2008 11:05 +0100, Jan Kara wrote:
> For example ext2 on fsync() just sync's a single inode
> (and has to use private_list to track metadata buffers associated with
> the inode) while ext3 flushes the whole journal.
As for fsync(), we definitely need to preserve correct behaviour for th
On Jan 24, 2008 17:25 -0700, Zan Lynx wrote:
> Have y'all been following the /dev/mem_notify patches?
> http://article.gmane.org/gmane.linux.kernel/628653
Having the notification be via poll() is a very restrictive processing
model. Having the notification be via a signal means that any kind of
(updated for thinko: when proper flag *is* set on both primary & backup)
Recent e2fsprogs (1.40.3 and higher) fsck compares primary superblock to
backups, and if things differ, it forces a full check. However, the
kernel has a penchant for updating flags the first time a feature is
used - attrib
> AIX basically did this with SIGDANGER (the signal is ignored by
> default), except there wasn't the ability for the process to tell the
> kernel at what level of memory pressure before it should start getting
> notified, and there was no way for the kernel to tell how bad the
> memory pressure ac
On Fri, Jan 25, 2008 at 10:34:25AM -0600, Eric Sandeen wrote:
> > But it was this concern which is why ext3 never exported freeze
> > functionality to userspace, even though other commercial filesystems
> > do support this. It wasn't that it wasn't considered, but the concern
> > about whether or
Theodore Tso wrote:
> The other approach would be to say, "oh well, the freeze ioctl is
> inherently dangerous, and root is allowed to himself in the foot, so
> who cares". :-)
I tend to agree. Either you need your fs frozen, or not, and if you do,
be prepared for the consequences.
> But it was
Andreas Dilger <[EMAIL PROTECTED]> writes:
> I was looking through the SLES10 e2fsprogs patch set, and I wonder if some
> of them could be integrated upstream, and if any effort had been made in
> that direction in the past? In particular, the addition of et_list_lock()
> and et_list_unlock() to
On Fri, Jan 25, 2008 at 03:18:51PM +0300, Dmitri Monakhov wrote:
> First of all Linux already have at least one open-source(dm-snap),
> and several commercial snapshot solutions.
Yes, but it requires that the filesystem be stored under LVM. Unlike
what EVMS v1 allowed us to do, we can't currentl
Hi,
I am also wondering whether we should have system call(s) for these:
On Jan 25, 2008 12:59 PM, Takashi Sato <[EMAIL PROTECTED]> wrote:
+ case EXT3_IOC_FREEZE: {
+ case EXT3_IOC_THAW: {
And just convert XFS to use them too?
I think it is reasonable to implement it as the
On 19:59 Fri 25 Jan , Takashi Sato wrote:
> Hi,
>
> Currently, ext3 doesn't have the freeze feature which suspends write
> requests. So, we cannot get a backup which keeps the filesystem's
> consistency with the storage device's features (snapshot, replication)
> while it is mounted.
> In man
Hi,
> diff -uprN -X linux-2.6.24-rc8/Documentation/dontdiff
> linux-2.6.24-rc8/include/linux/ext3_fs_sb.h
> linux-2.6.24-rc8-freeze/include/linux/ext3_fs_sb.h
> --- linux-2.6.24-rc8/include/linux/ext3_fs_sb.h 2008-01-16 13:22:48.0
> +0900
> +++ linux-2.6.24-rc8-freeze/include/linux/ext3
Hi,
Currently, ext3 doesn't have the freeze feature which suspends write
requests. So, we cannot get a backup which keeps the filesystem's
consistency with the storage device's features (snapshot, replication)
while it is mounted.
In many case, a commercial filesystems (e.g. VxFS) has the freeze
Hi,
> On Jan 23, 2008 11:53 -0500, Theodore Tso wrote:
> > Since I'm still hoping that
> > some point in the future, fs/ext4 could subsume fs/ext3 so we don't
> > have to worry about bug fixes going into fs/ext2 AND fs/ext3 AND
> > fs/ext4, I have my own reasons for wanting that.
>
> If any ne
20 matches
Mail list logo
