ext2resize-devel Mailing List for GNU ext2resize (Page 4)
Status: Inactive
Brought to you by:
adilger
Menu
▾
▴
ext2resize-devel
You can subscribe to this list here.
| 2000 |
Jan
|
Feb
|
Mar
(8) |
Apr
(1) |
May
|
Jun
(3) |
Jul
|
Aug
|
Sep
(6) |
Oct
|
Nov
(5) |
Dec
(2) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2001 |
Jan
|
Feb
|
Mar
(6) |
Apr
(2) |
May
|
Jun
|
Jul
(3) |
Aug
(2) |
Sep
|
Oct
(5) |
Nov
(5) |
Dec
|
| 2002 |
Jan
(14) |
Feb
(8) |
Mar
(5) |
Apr
|
May
|
Jun
|
Jul
(3) |
Aug
(3) |
Sep
(12) |
Oct
(12) |
Nov
(10) |
Dec
(10) |
| 2003 |
Jan
|
Feb
(7) |
Mar
(1) |
Apr
(6) |
May
(3) |
Jun
|
Jul
(3) |
Aug
(3) |
Sep
(2) |
Oct
(4) |
Nov
(1) |
Dec
(2) |
| 2004 |
Jan
(3) |
Feb
(2) |
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
(2) |
Aug
|
Sep
(2) |
Oct
|
Nov
|
Dec
|
| 2005 |
Jan
(2) |
Feb
|
Mar
|
Apr
|
May
(2) |
Jun
|
Jul
|
Aug
(14) |
Sep
(4) |
Oct
|
Nov
|
Dec
(5) |
| 2006 |
Jan
|
Feb
(4) |
Mar
(19) |
Apr
(1) |
May
(9) |
Jun
(34) |
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Richard J M. <ric...@uk...> - 2005-09-05 22:13:13
|
I have used ext3resize to shrink /dev/hda2 from 55GB to 9GB, but the partition table has not been updated and so the free space is not accessible. If I run: ext2resize /dev/hda2 9GB a second time I am told that the size is already 9GB. If I reboot my system and dump the partition table under fdisk the size is unaltered at 55GB. If I run KDiskFree it report 9.2GB as the partition size. The version of ext2resize I am using is 1.1.18 and I'm running having booted the Fedora core 4 rescue disc. Anyone have any ideas on how to get the partition table updated? - - Richard J Moore IBM Advanced Linux Response Team - Linux Technology Centre |
|
From: Glauber de O. C. <go...@br...> - 2005-09-01 23:01:04
|
Hi. Here is my new trial for the resize lock issue. Basically, it goes as follows: To ensure that only one resizer is running at a time, I added a global lock that is acquired in the very beginning of ext3_group_add and ext3_group_extend. lock_super is now only used in ext3_group_add in the moment we alter s_groups_count, and released after the super block is marked dirty. In ext3_group_extend, this is done outside the main function, so we can do it trusting the lock to be already held while in remount, or acquiring it explicitly while in ioctl. The lock in ext3_setup_new_group_blocks was simply wiped out, since this is always called from one of the functions that already holds the lock (and thus, in a safe environment) Signed-off-by: Glauber de Oliveira Costa <go...@br...> -- ===================================== Glauber de Oliveira Costa IBM Linux Technology Center - Brazil go...@br... ===================================== |
|
From: Stephen C. T. <sc...@re...> - 2005-08-31 13:31:49
|
Hi, On Wed, 2005-08-31 at 12:35, Glauber de Oliveira Costa wrote: > At a first look, i thought about locking gdt-related data. But in a > closer one, it seemed to me that we're in fact modifying a little bit > more than that in the resize code. But all these modifications seem to > be somehow related to the ext3 super block specific data in > ext3_sb_info. My first naive approach would be adding a lock to that > struct I took great care when making that code SMP-safe to avoid such locks, for performance reasons. See the comments at * We need to protect s_groups_count against other CPUs seeing * inconsistent state in the superblock. in fs/ext3/resize.c for the rules. But basically the way it works is that we only usually modify data that cannot be in use by other parts of the kernel --- and that's fairly easy to guarantee, since by definition extending the fs is something that is touching bits that aren't already in use. Only once all the new data is safely installed do we atomically update the s_groups_count field, which instantly makes the new data visible. We enforce this ordering via smp read barriers before reading s_groups_count and write barriers after modifying it, but we don't actually have locks as such. The only use of locking in the resize is hence the superblock lock, which is not really there to protect the resize from the rest of the fs --- the s_groups_count barriers do that. All the sb lock is needed for is to prevent two resizes from progressing at the same time; and that could easily be abstracted into a separate resize lock. Cheers, Stephen |
|
From: Glauber de O. C. <go...@br...> - 2005-08-31 11:31:05
|
> > The two different uses of the superblock lock are really quite > different; I don't see any particular problem with using two different > locks for the two different things. Mount and the namespace code are > not locking the same thing --- the fact that the resize code uses the > superblock lock is really a historical side-effect of the fact that we > used to use the same overloaded superblock lock in the ext2/ext3 block > allocation layers to guard bitmap access. > > At a first look, i thought about locking gdt-related data. But in a closer one, it seemed to me that we're in fact modifying a little bit more than that in the resize code. But all these modifications seem to be somehow related to the ext3 super block specific data in ext3_sb_info. My first naive approach would be adding a lock to that struct Besides that, by doing that, we become pretty much independent of vfs locking decisions to handle ext3 data. Do you think it all make sense? -- ===================================== Glauber de Oliveira Costa IBM Linux Technology Center - Brazil go...@br... ===================================== |
|
From: Stephen C. T. <sc...@re...> - 2005-08-30 14:07:47
|
Hi, On Thu, 2005-08-25 at 21:43, Glauber de Oliveira Costa wrote: > Just a question here. With s_lock held by the remount code, we're > altering the struct super_block, and believing we're safe. We try to > acquire it inside the resize functions, because we're trying to modify > this same data. Thus, if we rely on another lock, aren't we probably > messing up something ? The two different uses of the superblock lock are really quite different; I don't see any particular problem with using two different locks for the two different things. Mount and the namespace code are not locking the same thing --- the fact that the resize code uses the superblock lock is really a historical side-effect of the fact that we used to use the same overloaded superblock lock in the ext2/ext3 block allocation layers to guard bitmap access. --Stephen |
|
From: Glauber de O. C. <go...@br...> - 2005-08-25 21:19:04
|
BTW, something I forgot to mention: I was using ext2resize 1.1.17 at
that time.
1.1.19 worked fine, but I could not compile it on my system until I
changed the definition of BLKGETSIZE64 at ext2_unix_io.c
from
#define BLKGETSIZE64 _IOR(0x12,114,sizeof(unsigned long long))
to
#define BLKGETSIZE64 _IOR(0x12,114,unsigned long long)
That was a quick fix, and I have no time to get a more detailed reason
about which impacts would it bring on other parts of the code . Does it
make sense to you ?
glauber
On Tue, Aug 23, 2005 at 07:02:15PM -0600, Andreas Dilger wrote:
> On Aug 23, 2005 13:42 -0300, Glauber de Oliveira Costa wrote:
> > I'm starting to go trough the online resizing code for ext3, but I'm
> > having some troubles with it. It would be nice if someone could point me
> > the right direction. Maybe I'm doing something silly at all...
> >
> > Let me by now just describe what I'm doing, and which results I'm getting.
> >
> > I first tried the ext2online userspace tool, but got no success with it.
> > It returned me the error message bellow:
> >
> > ext2online: ext2_open: fs has unsupported feature(s) enabled:ext2online:
> > can't open /home/glauber/teste
>
> If you are using the latest e2fsprogs it should have proper support
> for online resizing (ext2online is part of e2fsprogs).
>
> > 1) the resize option was not even being parsed, and so I changed the
> > code in super.c to be like this:
> > {Opt_resize, "resize=%u"},
> > {Opt_err, NULL},
>
> I just noticed this myself recently.
>
> Cheers, Andreas
> --
> Andreas Dilger
> Principal Software Engineer
> Cluster File Systems, Inc.
>
|
|
From: Glauber de O. C. <go...@br...> - 2005-08-25 20:41:58
|
> NAK, this is wrong: > > > + lock_super(sb); > > err = ext3_group_extend(sb, EXT3_SB(sb)->s_es, n_blocks_count); > > + unlock_super(sb); > > This basically reverses the order of locking between lock_super() and > journal_start() (the latter acts like a lock because it can block on a > resource if the journal is too full for the new transaction.) That's > the opposite order to normal, and will result in a potential deadlock. > Ooops! Missed that. But I agree with the point. > But the _right_ fix, if you really want to keep that code, is probably > to move all the resize locking to a separate lock that ranks outside the > journal_start. The easy workaround is to drop the superblock lock and > reaquire it around the journal_start(); it would be pretty easy to make > that work robustly as far as ext3 is concerned, but I suspect there may > be VFS-layer problems if we start dropping the superblock lock in the > middle of the s_ops->remount() call --- Al? > Just a question here. With s_lock held by the remount code, we're altering the struct super_block, and believing we're safe. We try to acquire it inside the resize functions, because we're trying to modify this same data. Thus, if we rely on another lock, aren't we probably messing up something ? (for example, both group_extend and remount code potentially modify s_flags field. If we ioctl and remount at the same time, each one with a different lock, something could go wrong). Am I missing something here ? glauber |
|
From: Theodore Ts'o <ty...@mi...> - 2005-08-25 19:14:58
|
On Thu, Aug 25, 2005 at 12:14:21PM -0600, Andreas Dilger wrote: > > In particular, although it's been a while and so I can't remember all > > of the details, but IIRC, the tools which moves blocks around to make > > room for the resize inode scared me a little, and would require a > > bunch of rework before I would be comfortable with it. Integrating it > > is in my todo list, but for now, at least Red Hat/Fedora deals with > > this by including both the source packages in their SRPM, and building > > pieces of both. > > Oh, I thought ext2online (which is mostly just an ioctl driver for the > kernel resizing) was part of e2fsprogs. Was that only in the RH/FC > e2fsprogs 1.36 release? I think so, yes; it came out of the ext2resize source tree. > Maybe you are thinking of ext2prepare? It would probably be as good > or better to use the resize2fs itable moving and then the e2fsck code > for recreating the resize inode. That would avoid the addition of > a whole bunch of duplicate code to e2fsprogs. Yup, that's what I'm thinking about. My plan was to use the resize2fs itable moving code, combined with a user-space journaling scheme implemented layered on top of unix_io to protect the filesystem in case of a system crash. We need this in order to implement inode resizing for people who wants to use a larger inode size without doing a dump/restore, anyway.... - Ted |
|
From: Stephen C. T. <sc...@re...> - 2005-08-25 19:03:17
|
Hi,
On Wed, 2005-08-24 at 22:03, Glauber de Oliveira Costa wrote:
> This simple patch provides a fix for a locking issue found in the online
> resizing code. The problem actually happened while trying to resize the
> filesystem trough the resize=xxx option in a remount.
NAK, this is wrong:
> + lock_super(sb);
> err = ext3_group_extend(sb, EXT3_SB(sb)->s_es, n_blocks_count);
> + unlock_super(sb);
This basically reverses the order of locking between lock_super() and
journal_start() (the latter acts like a lock because it can block on a
resource if the journal is too full for the new transaction.) That's
the opposite order to normal, and will result in a potential deadlock.
> + {Opt_resize, "resize=%u"},
> {Opt_err, NULL},
> - {Opt_resize, "resize"},
Right, that's disabled for now. I guess the easy fix here is just to
remove the code entirely, given that we have locking problems with
trying to fix it!
But the _right_ fix, if you really want to keep that code, is probably
to move all the resize locking to a separate lock that ranks outside the
journal_start. The easy workaround is to drop the superblock lock and
reaquire it around the journal_start(); it would be pretty easy to make
that work robustly as far as ext3 is concerned, but I suspect there may
be VFS-layer problems if we start dropping the superblock lock in the
middle of the s_ops->remount() call --- Al?
--Stephen
|
|
From: Andreas D. <ad...@cl...> - 2005-08-25 18:14:44
|
On Aug 25, 2005 12:11 -0400, Theodore Ts'o wrote: > On Tue, Aug 23, 2005 at 07:02:15PM -0600, Andreas Dilger wrote: > > If you are using the latest e2fsprogs it should have proper support > > for online resizing (ext2online is part of e2fsprogs). > > In particular, although it's been a while and so I can't remember all > of the details, but IIRC, the tools which moves blocks around to make > room for the resize inode scared me a little, and would require a > bunch of rework before I would be comfortable with it. Integrating it > is in my todo list, but for now, at least Red Hat/Fedora deals with > this by including both the source packages in their SRPM, and building > pieces of both. Oh, I thought ext2online (which is mostly just an ioctl driver for the kernel resizing) was part of e2fsprogs. Was that only in the RH/FC e2fsprogs 1.36 release? Maybe you are thinking of ext2prepare? It would probably be as good or better to use the resize2fs itable moving and then the e2fsck code for recreating the resize inode. That would avoid the addition of a whole bunch of duplicate code to e2fsprogs. Cheers, Andreas -- Andreas Dilger Principal Software Engineer Cluster File Systems, Inc. |
|
From: Theodore Ts'o <ty...@mi...> - 2005-08-25 16:11:34
|
On Tue, Aug 23, 2005 at 07:02:15PM -0600, Andreas Dilger wrote: > > I first tried the ext2online userspace tool, but got no success with it. > > It returned me the error message bellow: > > > > ext2online: ext2_open: fs has unsupported feature(s) enabled:ext2online: > > can't open /home/glauber/teste > > If you are using the latest e2fsprogs it should have proper support > for online resizing (ext2online is part of e2fsprogs). Actually, it isn't. I've integrated the e2fsck and mke2fs and libext2fs changes, and fixed the resize2fs so it won't corrupt filesystems with the online resizing bit set, but I haven't integrated the rest of the on-line resizing tools yet. In particular, although it's been a while and so I can't remember all of the details, but IIRC, the tools which moves blocks around to make room for the resize inode scared me a little, and would require a bunch of rework before I would be comfortable with it. Integrating it is in my todo list, but for now, at least Red Hat/Fedora deals with this by including both the source packages in their SRPM, and building pieces of both. - Ted |
|
From: Glauber de O. C. <go...@br...> - 2005-08-24 21:01:52
|
This simple patch provides a fix for a locking issue found in the online
resizing code. The problem actually happened while trying to resize the
filesystem trough the resize=xxx option in a remount.
Signed-off-by: Glauber de Oliveira Costa <go...@br...>
diff -up linux-2.6.13-rc6-orig/fs/ext3/ioctl.c linux/fs/ext3/ioctl.c
--- linux-2.6.13-rc6-orig/fs/ext3/ioctl.c 2005-08-24 17:48:22.000000000 -0300
+++ linux/fs/ext3/ioctl.c 2005-08-24 15:12:48.000000000 -0300
@@ -206,7 +206,9 @@ flags_err:
if (get_user(n_blocks_count, (__u32 __user *)arg))
return -EFAULT;
+ lock_super(sb);
err = ext3_group_extend(sb, EXT3_SB(sb)->s_es, n_blocks_count);
+ unlock_super(sb);
journal_lock_updates(EXT3_SB(sb)->s_journal);
journal_flush(EXT3_SB(sb)->s_journal);
journal_unlock_updates(EXT3_SB(sb)->s_journal);
Only in linux/fs/ext3: patch-mnt_resize
diff -up linux-2.6.13-rc6-orig/fs/ext3/resize.c linux/fs/ext3/resize.c
--- linux-2.6.13-rc6-orig/fs/ext3/resize.c 2005-08-24 17:48:22.000000000 -0300
+++ linux/fs/ext3/resize.c 2005-08-24 15:15:28.000000000 -0300
@@ -884,7 +884,9 @@ exit_put:
/* Extend the filesystem to the new number of blocks specified. This entry
* point is only used to extend the current filesystem to the end of the last
* existing group. It can be accessed via ioctl, or by "remount,resize=<size>"
- * for emergencies (because it has no dependencies on reserved blocks).
+ * for emergencies (because it has no dependencies on reserved blocks).
+ *
+ * It should be called with sb->s_lock held
*
* If we _really_ wanted, we could use default values to call ext3_group_add()
* allow the "remount" trick to work for arbitrary resizing, assuming enough
@@ -959,7 +961,6 @@ int ext3_group_extend(struct super_block
goto exit_put;
}
- lock_super(sb);
if (o_blocks_count != le32_to_cpu(es->s_blocks_count)) {
ext3_warning(sb, __FUNCTION__,
"multiple resizers run on filesystem!\n");
@@ -978,7 +979,6 @@ int ext3_group_extend(struct super_block
es->s_blocks_count = cpu_to_le32(o_blocks_count + add);
ext3_journal_dirty_metadata(handle, EXT3_SB(sb)->s_sbh);
sb->s_dirt = 1;
- unlock_super(sb);
ext3_debug("freeing blocks %ld through %ld\n", o_blocks_count,
o_blocks_count + add);
ext3_free_blocks_sb(handle, sb, o_blocks_count, add, &freed_blocks);
diff -up linux-2.6.13-rc6-orig/fs/ext3/super.c linux/fs/ext3/super.c
--- linux-2.6.13-rc6-orig/fs/ext3/super.c 2005-08-24 17:48:22.000000000 -0300
+++ linux/fs/ext3/super.c 2005-08-24 15:13:16.000000000 -0300
@@ -639,8 +639,8 @@ static match_table_t tokens = {
{Opt_quota, "quota"},
{Opt_quota, "usrquota"},
{Opt_barrier, "barrier=%u"},
+ {Opt_resize, "resize=%u"},
{Opt_err, NULL},
- {Opt_resize, "resize"},
};
static unsigned long get_sb_block(void **data)
|
|
From: Andreas D. <ad...@cl...> - 2005-08-24 17:59:12
|
On Aug 24, 2005 13:40 -0300, Glauber de Oliveira Costa wrote: > besides that, there is also the locking issue, that is not gone away. In > a fast look into the code, I realized that ext3_group_extend is only > called by either fs/super.c or fs/ext3/ioctl.c. Since the problem arises > from a mount call (as do_remount_sb already holds the lock), and > changing that would be a little vfs-intrusive, I think that the best > solution is to remove the lock code from ext3_group_extend, and get > it before its call in ioctl. This way, the whole ext3_group_extend > would be called with the super block lock held. This is pretty reasonable. I've had to do similar things in the past as the VFS locking changes. Cheers, Andreas -- Andreas Dilger Principal Software Engineer Cluster File Systems, Inc. |
|
From: Glauber de O. C. <go...@br...> - 2005-08-24 16:40:05
|
Andreas, besides that, there is also the locking issue, that is not gone away. In a fast look into the code, I realized that ext3_group_extend is only called by either fs/super.c or fs/ext3/ioctl.c. Since the problem arises from a mount call (as do_remount_sb already holds the lock), and changing that would be a little vfs-intrusive, I think that the best solution is to remove the lock code from ext3_group_extend, and get it before its call in ioctl. This way, the whole ext3_group_extend would be called with the super block lock held. What do you think? glauber. -- ===================================== Glauber de Oliveira Costa IBM Linux Technology Center - Brazil go...@br... ===================================== |
|
From: Andreas D. <ad...@cl...> - 2005-08-24 01:02:40
|
On Aug 23, 2005 13:42 -0300, Glauber de Oliveira Costa wrote:
> I'm starting to go trough the online resizing code for ext3, but I'm
> having some troubles with it. It would be nice if someone could point me
> the right direction. Maybe I'm doing something silly at all...
>
> Let me by now just describe what I'm doing, and which results I'm getting.
>
> I first tried the ext2online userspace tool, but got no success with it.
> It returned me the error message bellow:
>
> ext2online: ext2_open: fs has unsupported feature(s) enabled:ext2online:
> can't open /home/glauber/teste
If you are using the latest e2fsprogs it should have proper support
for online resizing (ext2online is part of e2fsprogs).
> 1) the resize option was not even being parsed, and so I changed the
> code in super.c to be like this:
> {Opt_resize, "resize=%u"},
> {Opt_err, NULL},
I just noticed this myself recently.
Cheers, Andreas
--
Andreas Dilger
Principal Software Engineer
Cluster File Systems, Inc.
|
|
From: Glauber de O. C. <go...@br...> - 2005-08-23 16:42:10
|
Hi all,
I'm starting to go trough the online resizing code for ext3, but I'm
having some troubles with it. It would be nice if someone could point me
the right direction. Maybe I'm doing something silly at all...
Let me by now just describe what I'm doing, and which results I'm getting.
I first tried the ext2online userspace tool, but got no success with it.
It returned me the error message bellow:
ext2online: ext2_open: fs has unsupported feature(s) enabled:ext2online:
can't open /home/glauber/teste
Since I'm using 2.6.13-rc6, in which the resizing patches should be
merged already, I can't guess which support it's about.
But that's okay, life goes on. I then tried doing it directly by passing
the resize=blocks parameter to mount (obviously, while remounting), and
found 2 main issues, that are:
1) the resize option was not even being parsed, and so I changed the
code in super.c to be like this:
{Opt_resize, "resize=%u"},
{Opt_err, NULL},
2) With that done, my mount process hung while trying to acquire a lock
in ext3_group_extend , at resize.c. Actually, this lock was already held
by do_remount_sb.
Having all these sort of problems, I realized that I would maybe be
doing something very wrong. As I said earlier, any enlightenment may be
helpful.
Thanks,
glauber
--
=====================================
Glauber de Oliveira Costa
IBM Linux Technology Center - Brazil
go...@br...
=====================================
|
|
From: Andreas D. <ad...@cl...> - 2005-01-21 23:07:38
|
On Jan 12, 2005 14:47 +0000, Alex Owen wrote: > I believe there is a bug in the definition of BLKGETSIZE64 in > ext2resize-1.1.19/src/ext2_unix_io.c >=20 > I believe that this patch fixes the problem: > ---8<--- > --- ext2resize-1.1.19/src/ext2_unix_io.c 2004-09-30 15:04:04.00000= 0000 +0100 > +++ ext2resize-1.1.19.works/src/ext2_unix_io.c 2005-01-11 17:56:14.00000= 0000 +0000 > @@ -47,7 +47,7 @@ > #endif >=20 > #ifndef BLKGETSIZE64 > -#define BLKGETSIZE64 _IOR(0x12,114,sizeof(unsigned long long)) > +#define BLKGETSIZE64 _IOR(0x12,114,unsigned long long) > #endif >=20 > struct my_cookie Thanks, I've committed this change to CVS. Cheers, Andreas -- Andreas Dilger http://sourceforge.net/projects/ext2resize/ http://members.shaw.ca/adilger/ http://members.shaw.ca/golinux/ |
|
From: Alex O. <ra...@le...> - 2005-01-12 14:48:08
|
I believe there is a bug in the definition of BLKGETSIZE64 in
ext2resize-1.1.19/src/ext2_unix_io.c
I believe that this patch fixes the problem:
---8<---
--- ext2resize-1.1.19/src/ext2_unix_io.c 2004-09-30 15:04:04.000000000 +0100
+++ ext2resize-1.1.19.works/src/ext2_unix_io.c 2005-01-11 17:56:14.000000000 +0000
@@ -47,7 +47,7 @@
#endif
#ifndef BLKGETSIZE64
-#define BLKGETSIZE64 _IOR(0x12,114,sizeof(unsigned long long))
+#define BLKGETSIZE64 _IOR(0x12,114,unsigned long long)
#endif
struct my_cookie
---8<---
Analysis
========
This bug concealed when compiling against old versions of asm/ioctl.h.
My experiance is with debian so bear with me...
The vanilla ext2resize-1.1.19 source builds without reporting the bug on a
debian woody(stable) system where /usr/include/asm/ioctl.h
is provided provided by package libc6-dev version 2.2.5-11.5.
The vanilla ext2resize-1.1.19 source reports a bug when built on a
debian sarge(testing) system where /usr/include/asm/ioctl.h
is provided provided by package linux-kernel-headers 2.5.999-test7-bk-16.
The diff between versions of /usr/include/asm/ioctl.h is only small and
the comments show that _IOR was changed to trap such bugs as this
one at compile time.
---8<---
--- old-ioctl.h 2005-01-12 14:38:32.000000000 +0000
+++ /usr/include/asm/ioctl.h 2004-06-02 04:59:44.000000000 +0100
@@ -52,11 +52,21 @@
((nr) << _IOC_NRSHIFT) | \
((size) << _IOC_SIZESHIFT))
+/* provoke compile error for invalid uses of size argument */
+extern unsigned int __invalid_size_argument_for_IOC;
+#define _IOC_TYPECHECK(t) \
+ ((sizeof(t) == sizeof(t[1]) && \
+ sizeof(t) < (1 << _IOC_SIZEBITS)) ? \
+ sizeof(t) : __invalid_size_argument_for_IOC)
+
/* used to create numbers */
#define _IO(type,nr) _IOC(_IOC_NONE,(type),(nr),0)
-#define _IOR(type,nr,size) _IOC(_IOC_READ,(type),(nr),sizeof(size))
-#define _IOW(type,nr,size) _IOC(_IOC_WRITE,(type),(nr),sizeof(size))
-#define _IOWR(type,nr,size)
_IOC(_IOC_READ|_IOC_WRITE,(type),(nr),sizeof(size))
+#define _IOR(type,nr,size)
_IOC(_IOC_READ,(type),(nr),(_IOC_TYPECHECK(size)))
+#define _IOW(type,nr,size)
_IOC(_IOC_WRITE,(type),(nr),(_IOC_TYPECHECK(size)))
+#define _IOWR(type,nr,size)
_IOC(_IOC_READ|_IOC_WRITE,(type),(nr),(_IOC_TYPECHECK(size)))
+#define _IOR_BAD(type,nr,size) _IOC(_IOC_READ,(type),(nr),sizeof(size))
+#define _IOW_BAD(type,nr,size) _IOC(_IOC_WRITE,(type),(nr),sizeof(size))
+#define _IOWR_BAD(type,nr,size)
_IOC(_IOC_READ|_IOC_WRITE,(type),(nr),sizeof(size))
/* used to decode ioctl numbers.. */
#define _IOC_DIR(nr) (((nr) >> _IOC_DIRSHIFT) & _IOC_DIRMASK)
---8<---
I hope this helps...
Alex Owen
|
|
From: Andreas D. <ad...@cl...> - 2004-09-27 16:24:21
|
On Sep 27, 2004 09:55 +1000, Andrew Jackson wrote:
> Has anyone had any luck applying the online-ext2 patch to 2.4.27 ?
>=20
> Looks like it broke somewhere around 2.4.21.
>=20
> Hunk #7 succeeded at 1726 (offset 26 lines).
> 1 out of 7 hunks FAILED -- saving rejects to file fs/ext3/super.c.rej
> patching file include/linux/ext3_fs.h
> Hunk #2 succeeded at 460 (offset 1 line).
>=20
> this is the reject file....
>=20
> ***************
> *** 1660,1666 ****
>=20
> es =3D sbi->s_es;
>=20
> - if ((*flags & MS_RDONLY) !=3D (sb->s_flags & MS_RDONLY)) {
> if (sbi->s_mount_opt & EXT3_MOUNT_ABORT)
> return -EROFS;
>=20
> --- 1684,1691 ----
>=20
> es =3D sbi->s_es;
>=20
> + if ((*flags & MS_RDONLY) !=3D (sb->s_flags & MS_RDONLY) ||
> + n_blocks_count > le32_to_cpu(es->s_blocks_count)) {
> if (sbi->s_mount_opt & EXT3_MOUNT_ABORT)
> return -EROFS;
>=20
>=20
> Strange that in the first chunk it removes the if statement with the
> starting curly bracket, but the matching curly bracket is not removed.
Well, the second chunk is replacing that curly brace... Looks like the
only change is that there is now a "ext3_init_journal_params(...)" call
and it adds a line with just a <tab> that breaks the patch context. Fix
is to just use editor to delete first (-) line from ext3_remount() and
replace it with second (+) lines.
PS - you don't need the online patch to do offline filesystem resizing,
and since your kernel doesn't already have this patch and you need
to reboot to get it, you may as well do an offline resize the first
time...
Cheers, Andreas
--
Andreas Dilger
http://sourceforge.net/projects/ext2resize/
http://members.shaw.ca/adilger/ http://members.shaw.ca/golinux/
|
|
From: Andrew J. <and...@ne...> - 2004-09-26 23:55:25
|
Has anyone had any luck applying the online-ext2 patch to 2.4.27 ?
Looks like it broke somewhere around 2.4.21.
Hunk #7 succeeded at 1726 (offset 26 lines).
1 out of 7 hunks FAILED -- saving rejects to file fs/ext3/super.c.rej
patching file include/linux/ext3_fs.h
Hunk #2 succeeded at 460 (offset 1 line).
this is the reject file....
***************
*** 1660,1666 ****
es = sbi->s_es;
- if ((*flags & MS_RDONLY) != (sb->s_flags & MS_RDONLY)) {
if (sbi->s_mount_opt & EXT3_MOUNT_ABORT)
return -EROFS;
--- 1684,1691 ----
es = sbi->s_es;
+ if ((*flags & MS_RDONLY) != (sb->s_flags & MS_RDONLY) ||
+ n_blocks_count > le32_to_cpu(es->s_blocks_count)) {
if (sbi->s_mount_opt & EXT3_MOUNT_ABORT)
return -EROFS;
Strange that in the first chunk it removes the if statement with the
starting curly bracket, but the matching curly bracket is not removed.
I am looking at doing an online resize on a 80GB RAID Array which hosts
5000+ clients. So getting this to work 100% is my primary goal.
Thanks in advance.
--
Andrew Jackson
Systems Administrator
NetRegistry Pty Ltd
_______________________________________________
http://www.netregistry.com.au/
Tel: +61 2 96996099 | Fax: +61 2 96996088
PO Box 270 Broadway | NSW 2007, Australia
Your Total Internet Business Services Provider
Trusted by 10,000s of Oz Businesses Since 1997
|
|
From: Andreas D. <ad...@cl...> - 2004-07-12 21:02:22
|
On Jul 12, 2004 14:00 -0400, Joseph Fannin wrote: > Can ext2resize handle ext3 features like hash indexed directories > and extended attributes? I would prefer to use the version 1.1.17 in > Debian unstable, but building a more recent version wouldn't be a big > deal. I believe the version in CVS has the flags set to support dir_index. The resizer would need some more smarts to be able to shrink a filesystem with EAs, but for growing it there is no problem. Cheers, Andreas -- Andreas Dilger http://sourceforge.net/projects/ext2resize/ http://members.shaw.ca/adilger/ http://members.shaw.ca/golinux/ |
|
From: Joseph F. <jh...@ri...> - 2004-07-12 18:00:39
|
(Please keep me CC'd, as I'm not subscribed to ext2resize-devel).
Can ext2resize handle ext3 features like hash indexed directories
and extended attributes? I would prefer to use the version 1.1.17 in
Debian unstable, but building a more recent version wouldn't be a big
deal.
I'm planning moving only my data partitions to LVM, so unmounting
before resizing would work okay. For that matter, removing dir_index
and running fsck before resizing isn't that big a deal either, I
guess, but stripping all my acls before resizing would be a major
pain.
I suppose I won't need to resize a fs with acls in the immediate
future, but I'm trying to plan this well. Any help or advice is
appreciated, and thank you. :-)
--=20
Joseph Fannin
jh...@ri...
"Bull in pure form is rare; there is usually some contamination by data."
-- William Graves Perry Jr.
|
|
From: Rene L. <onf...@fa...> - 2004-06-26 14:26:50
|
The struggle alone pleases us, not the victory. The king is the man who can. Every act of virtue is an ingredient unto reward. I am the Fred Astaire of karate. If a man has done his best, what else is there? The world cares very little about what a man or woman knows it is what a man or woman is able to do that counts. Crime generally punishes itself. You never really know a man until you have divorced him. Knowledge is of no value unless you put it into practice. I want to do a musical movie. Like Evita, but with good music. The ego is not master in its own house. Thought is the blossom language the bud action the fruit behind it. Nothing is interesting if you are not interested. A sub-clerk in the post-office is the equal of a conqueror if consciousness is common to them. |
|
From: Jaime T. <jt...@ce...> - 2004-02-06 17:35:58
|
Hi, I used ext2resize to shrink an ext3 partition. Everything worked smoothly and the new size of it is, in fact, reduced. Now I want to use the extra space to create a new partition but fdisk doesn't find any free space on the disk. What should I do to create a new partition and start using it? Thanks for your help, Jaime |
|
From: Daniel R. <ma...@al...> - 2004-01-07 13:00:13
|
Neither the ext2resize home page nor the FAQ discusses whether the ext2resize tools work with ext3 or whether the kernel patches are needed (or even available) for kernels later than 2.3. This would be an easy and useful change to the web page. Thanks for your consideration. |
5 messages has been excluded from this view by a project administrator.
