1

Topic: gparted extremeliy slow + resize action not allowed: vfat

Hello, I just checked on the forum similar problems.
gparted, however has a good looking, thanks for that.

I use a debian 4.0 etch (from a net-install cd).
I installed on xfce4 + ivman for automount stuff.
I used debian packages
pkg                            version
libparted1.7-1             1.7.1-5.1
libgtkmm-2.4-1c2a      2.8.8-1
gparted                      0.2.5-2

Finally I got latest tarball gparted-0.3.3.tar.bz2, and updating devel corresponding packages,
I installed this version.
With no luck on improvement for speed or permission to resize (unmounted) vfat partition.
I cannot change any field nor resize with mouse.

Any Idea ?
Thanks, xoing

PS :
1) Using "parted" is quite ok for speed problem.
2) I tried the following on an xterminal (exactly an xfce-terminal):
# gparted
======================
libparted : 1.7.1
automounting disabled
======================
Unable to open /dev/fd0 read-write (Syst

2

Re: gparted extremeliy slow + resize action not allowed: vfat

You know you must be logged as root to perform anything with gparted ?
It must scan all device and contains, and sometimes it takes time. It usually comes from fat32 partitions ...

Larry
GParted-project Admin
Former GParted-LiveCD maintainer (2007)

3

Re: gparted extremeliy slow + resize action not allowed: vfat

Yes I'm logged as root.
Exactly I am "sub"-logged as root, in a normal xwindow user session.

But does fat32 leave to wait you for nearly 10 minutes ?
This is not "normal", isn't it ?
Also why no resize possibility on vfat partitions, when "features" tells it is allowed ?

Thanks, Xavier

4

Re: gparted extremeliy slow + resize action not allowed: vfat

Hi Xavier,
Scanning takes about 10 minutes ? I am not surprised : like i said (maybe another time) fat 32 is very long to scan. this may come from parted I  guess.
If resizing seems to be unavailable, double clic on hte file system : it should return the reason why it is not possible.
Does dostools installed on in your OS ?

Larry
GParted-project Admin
Former GParted-LiveCD maintainer (2007)

5

Re: gparted extremeliy slow + resize action not allowed: vfat

To move-resize fat fss, I thought only kernel vfat support was sufficient.
Indeed "mkdosfs" and related files were not present.
I just installed dostools, (i.e. dosfstools package for debian etch),
and resizing seems to bo ok. Sorry for that.

I tried to trace recursively those two with  strace command :

# strace -t -f -F -o gparted2.log gparted

and

# strace -t -f -F -o parted2.log parted

And I compared gparted2.log ans parted2.log files

For fat32 long access, do you know something about the code ?
As I read, on parted, gparted and parted share the same library.
But using the following commands with parted,

#parted /dev/hda
GNU Parted 1.7.1
Using /dev/hda
Welcome to GNU Parted! Type 'help' to view a list of commands.
(parted)

I am prompted immadiately to "(parted)" prompt.

No parameter gives about "30 seconds" to get prompt.

Giving or not "/dev/hda" parameter to gparted from command line doesn't
change (scan between 5 and 10 minutes).

debian:~# echo `head -n1 gparted2.log`;echo `tail -n1 pgparted2.log`
5980 11:49:09 execve("/usr/bin/gparted", ["gparted"], [/* 28 vars */]) = 0
5980 11:55:55 exit_group(0) = ?

debian:~# echo `head0 -n1 parted2.log`; echo `tail -n1 parted2.log`
6567 13:28:50 execve("/sbin/parted", ["parted"], [/* 28 vars */]) = 0
6567 13:29:16 read(0,

Also I get a 14MB (about 200 000 syscalls) gparted2.log file, while parted2.log is 60KB.
I get about 170 000 / 200 000 system calls of the following form. Hereafter are 2 series of these calls:

6231  12:33:12 write(3, "7\20\5\0-\1@\2l\0@\2\0\0\1\0\0\0\0\0;\3\5\0-\1@\2\0\0\0"..., 1076) = 1076
6231  12:33:12 ioctl(3, FIONREAD, [0])  = 0
6231  12:33:12 poll([{fd=4, events=POLLIN}, {fd=3, events=POLLIN}], 2, 0) = 0
6231  12:33:12 ioctl(3, FIONREAD, [0])  = 0
6231  12:33:12 poll([{fd=4, events=POLLIN}, {fd=3, events=POLLIN}], 2, 0) = 0
6231  12:33:12 write(3, "5\20\4\0/\1@\2a\0@\2\270\1\24\0\230\4\5\0000\1@\2/\1@\002"..., 192) = 192
6231  12:33:12 ioctl(3, FIONREAD, [0])  = 0
6231  12:33:12 poll([{fd=4, events=POLLIN}, {fd=3, events=POLLIN}], 2, 0) = 0
6231  12:33:12 nanosleep({0, 10000000}, NULL) = 0
6231  12:33:12 write(3, "7\20\5\0001\1@\2l\0@\2\0\0\1\0\0\0\0\0;\3\5\0001\1@\2\0"..., 1076) = 1076
6231  12:33:12 ioctl(3, FIONREAD, [0])  = 0
6231  12:33:12 poll([{fd=4, events=POLLIN}, {fd=3, events=POLLIN}], 2, 0) = 0
6231  12:33:12 ioctl(3, FIONREAD, [0])  = 0
6231  12:33:12 poll([{fd=4, events=POLLIN}, {fd=3, events=POLLIN}], 2, 0) = 0
6231  12:33:12 write(3, "5\20\4\0003\1@\2a\0@\2\270\1\24\0\230\4\5\0004\1@\0023"..., 192) = 192
6231  12:33:12 ioctl(3, FIONREAD, [0])  = 0
6231  12:33:12 poll([{fd=4, events=POLLIN}, {fd=3, events=POLLIN}], 2, 0) = 0
6231  12:33:12 nanosleep({0, 10000000}, NULL) = 0

May be these calls are only those related to the bar on the window, showing gparted is still
looking. But thus where could I find information concerning attempts of gparted to collect information.
As I am not an expert, may be this analysis completely unusefull and stupid.


Another thing: why 7 hard attempts to open /dev/fd0 using gparted (see below), while 2 are enough with parted ?

debian:~# grep -e 'open("/dev/fd0"' -e "open.*unfinished" -e "open resumed" gparted2.log
5985  11:49:10 open("/proc/mounts", O_RDONLY|O_LARGEFILE <unfinished ...>
5985  11:49:10 <... open resumed> )     = 6
5985  11:49:10 open("/dev/hdc", O_RDONLY|O_LARGEFILE <unfinished ...>
5985  11:49:10 <... open resumed> )     = -1 ENOMEDIUM (No medium found)
5985  11:49:10 open("/dev/fd0", O_RDWR|O_LARGEFILE <unfinished ...>
5985  11:49:23 <... open resumed> )     = -1 EROFS (Read-only file system)
5985  11:49:23 open("/dev/fd0", O_RDONLY|O_LARGEFILE <unfinished ...>
5985  11:49:36 <... open resumed> )     = 7
5985  11:49:36 open("/dev/hdc", O_RDONLY|O_LARGEFILE <unfinished ...>
5985  11:49:36 <... open resumed> )     = -1 ENOMEDIUM (No medium found)
5985  11:49:36 open("/dev/fd0", O_RDWR|O_LARGEFILE <unfinished ...>
5985  11:49:49 <... open resumed> )     = -1 EROFS (Read-only file system)
5985  11:49:49 open("/dev/fd0", O_RDONLY|O_LARGEFILE <unfinished ...>
5985  11:50:02 <... open resumed> )     = 6
5985  11:53:31 open("/dev/fd0", O_RDONLY|O_LARGEFILE <unfinished ...>
5985  11:53:45 <... open resumed> )     = 6
5985  11:53:45 open("/dev/fd0", O_RDWR|O_LARGEFILE <unfinished ...>
5985  11:53:58 <... open resumed> )     = -1 EROFS (Read-only file system)
5985  11:53:58 open("/dev/fd0", O_RDONLY|O_LARGEFILE <unfinished ...>
5985  11:54:11 <... open resumed> )     = 6
5985  11:54:37 open("/etc/mtab", O_RDONLY|O_LARGEFILE <unfinished ...>
5985  11:54:37 <... open resumed> )     = 7
5999  11:54:38 open("/dev/tty", O_RDWR|O_NONBLOCK|O_LARGEFILE <unfinished ...>
5999  11:54:38 <... open resumed> )     = 3
5999  11:54:38 open("/usr/lib/libhal.so.1", O_RDONLY <unfinished ...>
5999  11:54:38 <... open resumed> )     = 3
5999  11:54:38 open("/usr/lib/libdbus-1.so.3", O_RDONLY <unfinished ...>
5999  11:54:38 <... open resumed> )     = 3
6001  11:54:39 open("/dev/hda6", O_RDONLY|O_LARGEFILE <unfinished ...>
6001  11:54:39 <... open resumed> )     = 3
5985  11:54:39 open("/dev/hda1", O_WRONLY|O_LARGEFILE <unfinished ...>
5985  11:54:39 <... open resumed> )     = 7

Can you tell me if I this can help you ?
Do you know if "gparted" collects more information than parted while starting ?


Thanks, Xavier.

PS: a line on strace log file starts with the pid number, then date, and finally the system call

6

Re: gparted extremeliy slow + resize action not allowed: vfat

This for Plors, who's the main dev. I will try to contact him.... Be patient wink

Larry
GParted-project Admin
Former GParted-LiveCD maintainer (2007)