sd4l-user

[SD4L-user] mkfs hangs when creating large container from HD partition

[Jonathan C. <jco...@ro...>]

I have tried several times to create a Scramdisk container on a hard 
drive partition (about 24Gb). After several minutes of mouse waggling, 
Scramdisk begins encrypting and formatting the partition. This continues 
until the progress bar is near 100%. Then, the Scramdisk application 
becomes unresponsive. If you cover it with another window and then give 
it the focus again, Scramdisk does not restore its window. Running "ps 
ax" reveals that mkfs and Scramdisk are still running, but are asleep.

I am running Ubuntu 8.04 with kernel 2.6.24-19 and ScramDisk 1.3.0. 
Admittedly, this one was built for kernel 2.6.24-18, but container 
creation on flash memory cards and as .svl files works as it should.

Thanks.

Re: [SD4L-user] mkfs hangs when creating large container from HD partition

[Hans-Ulrich J. <han...@t-...>]

Hello Jonathan,

Jonathan Coles wrote:
 > I have tried several times to create a Scramdisk container on a hard 
drive partition (about 24Gb). After several minutes of mouse waggling, 
Scramdisk begins encrypting and formatting the partition. This continues 
until the progress bar is near 100%. Then, the Scramdisk application 
becomes unresponsive. If you cover it with another window and then give 
it the focus again, Scramdisk does not restore its window. Running "ps 
ax" reveals that mkfs and Scramdisk are still running, but are asleep.
 >
 > I am running Ubuntu 8.04 with kernel 2.6.24-19 and ScramDisk 1.3.0. 
Admittedly, this one was built for kernel 2.6.24-18, but container 
creation on flash memory cards and as .svl files works as it should.
 >
 > Thanks.

this could be a bug. However, in a quick test I failed to reproduce it.
If you can tell me what options you have chosen for the container -
especially the file system is relevant here - I'll try further to
reproduce and fix the problem.

Best regards
Ulrich

Re: [SD4L-user] mkfs hangs when creating large container from HD partition

[Jonathan C. <jco...@ro...>]

Hi Ulrich,

I changed two things from the Windows compatible default: Digest SHA256 
and file system ext2. The container size was automatically selected at 
23Gb, the remaining space on the drive.

Here's the end of "ps ax" output showing the sleeping (dead in the 
water?) processes:

 6803 pts/0    R      8:27 scramdisk
 6829 ?        S      0:00 [pdflush]
 6848 ?        S      0:02 [scramdisk01]
 6849 pts/0    S      0:00 mkfs.ext2 /dev/scramdisk/vol01
 6850 ?        S      0:00 [pdflush]

Now that I know how to avoid the lengthy mouse-waggling sessions, I can 
try a few more scenarios. Perhaps a smaller volume would work. Perhaps 
the Windows-compatible default would work.

Thanks.

Jonathan Coles wrote:
> I have tried several times to create a Scramdisk container on a hard 
> drive partition (about 24Gb). After several minutes of mouse waggling, 
> Scramdisk begins encrypting and formatting the partition. This continues 
> until the progress bar is near 100%. Then, the Scramdisk application 
> becomes unresponsive. If you cover it with another window and then give 
> it the focus again, Scramdisk does not restore its window. Running "ps 
> ax" reveals that mkfs and Scramdisk are still running, but are asleep.
>
> I am running Ubuntu 8.04 with kernel 2.6.24-19 and ScramDisk 1.3.0. 
> Admittedly, this one was built for kernel 2.6.24-18, but container 
> creation on flash memory cards and as .svl files works as it should.
>
> Thanks.
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> SD4L-user mailing list
> SD4...@li...
> https://lists.sourceforge.net/lists/listinfo/sd4l-user
>
>   

Re: [SD4L-user] mkfs hangs when creating large container from HD partition

[Jonathan C. <jco...@ro...>]

I just tried creating a default Windows-compatible Scramdisk container 
on a partition and it worked.
There is one odd thing. The size shows up as 75Gb, the size of the 
entire drive, not the 23Gb available in the empty partition. The other 
partitions are still there.

An attempt to create a smaller 15Gb ext2 Scramdisk failed. I might need 
to verify that mkfs.ext2 works OK on its own.

Jonathan Coles wrote:
> Hi Ulrich,
>
> I changed two things from the Windows compatible default: Digest SHA256 
> and file system ext2. The container size was automatically selected at 
> 23Gb, the remaining space on the drive.
>
> Here's the end of "ps ax" output showing the sleeping (dead in the 
> water?) processes:
>
>  6803 pts/0    R      8:27 scramdisk
>  6829 ?        S      0:00 [pdflush]
>  6848 ?        S      0:02 [scramdisk01]
>  6849 pts/0    S      0:00 mkfs.ext2 /dev/scramdisk/vol01
>  6850 ?        S      0:00 [pdflush]
>
> Now that I know how to avoid the lengthy mouse-waggling sessions, I can 
> try a few more scenarios. Perhaps a smaller volume would work. Perhaps 
> the Windows-compatible default would work.
>
> Thanks.
>
> Jonathan Coles wrote:
>   
>> I have tried several times to create a Scramdisk container on a hard 
>> drive partition (about 24Gb). After several minutes of mouse waggling, 
>> Scramdisk begins encrypting and formatting the partition. This continues 
>> until the progress bar is near 100%. Then, the Scramdisk application 
>> becomes unresponsive. If you cover it with another window and then give 
>> it the focus again, Scramdisk does not restore its window. Running "ps 
>> ax" reveals that mkfs and Scramdisk are still running, but are asleep.
>>
>> I am running Ubuntu 8.04 with kernel 2.6.24-19 and ScramDisk 1.3.0. 
>> Admittedly, this one was built for kernel 2.6.24-18, but container 
>> creation on flash memory cards and as .svl files works as it should.
>>
>> Thanks.
>>
>> -------------------------------------------------------------------------
>> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
>> Build the coolest Linux based applications with Moblin SDK & win great prizes
>> Grand prize is a trip for two to an Open Source event anywhere in the world
>> http://moblin-contest.org/redirect.php?banner_id=100&url=/
>> _______________________________________________
>> SD4L-user mailing list
>> SD4...@li...
>> https://lists.sourceforge.net/lists/listinfo/sd4l-user
>>
>>   
>>     
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> SD4L-user mailing list
> SD4...@li...
> https://lists.sourceforge.net/lists/listinfo/sd4l-user
>
>   

Re: [SD4L-user] mkfs hangs when creating large container from HD partition

[Hans-Ulrich J. <han...@t-...>]

Hi Jonathan,

Jonathan Coles wrote:
> I just tried creating a default Windows-compatible Scramdisk container 
> on a partition and it worked.
> There is one odd thing. The size shows up as 75Gb, the size of the 
> entire drive, not the 23Gb available in the empty partition. The other 
> partitions are still there.
> 
> An attempt to create a smaller 15Gb ext2 Scramdisk failed. I might need 
> to verify that mkfs.ext2 works OK on its own.
> 
> Jonathan Coles wrote:
>> Hi Ulrich,
>>
>> I changed two things from the Windows compatible default: Digest SHA256 
>> and file system ext2. The container size was automatically selected at 
>> 23Gb, the remaining space on the drive.
>>
>> Here's the end of "ps ax" output showing the sleeping (dead in the 
>> water?) processes:
>>
>>  6803 pts/0    R      8:27 scramdisk
>>  6829 ?        S      0:00 [pdflush]
>>  6848 ?        S      0:02 [scramdisk01]
>>  6849 pts/0    S      0:00 mkfs.ext2 /dev/scramdisk/vol01
>>  6850 ?        S      0:00 [pdflush]
>>
>> Now that I know how to avoid the lengthy mouse-waggling sessions, I can 
>> try a few more scenarios. Perhaps a smaller volume would work. Perhaps 
>> the Windows-compatible default would work.
>>
>> Thanks.

thank you for the detailed report. Just a little information on
the output of the ps command:
scramdisk with PID 6803 is the running GUI,
mkfs.ext2 with PID 6849 is the command started by the GUI for
making the file system,
the two [pdflush] processes with PID 6829 and 6850 are kernel
threads generally responsible for writing back file system data,
finally [scramdisk01] with PID 6848 is the kernel thread started
by the scramdisk kernel driver to handle input and output requests
on the first mounted container.

I'm especially worried about the odd observation that scramdisk
reports the size of the whole drive not of the partition you
wanted to create the container on. If somehow the device of the
whole drive has been chosen, a possible reason of the hanging
might have been that the kernel driver has mounted the device
read only because of missing access rights. If so, it's very
odd that the container has been created that far. But in that
case you have been lucky that the device wasn't overwritten.

In order to further investigate the problem could you please
check by "ls -l" the access rights of the devices of your whole
drive and the partition in question. Moreover, it might be
helpful to have a look at /var/log/messages what the scramdisk
kernel driver has reported on the event of the failed container
creation.

Best regards
Ulrich

Re: [SD4L-user] mkfs hangs when creating large container from HD partition

[Jonathan C. <jco...@ro...>]

Hi Ulrich,

> $ ls -l /dev/sda*
> brw-rw---- 1 root disk 8, 0 2008-08-04 12:44 /dev/sda
> brw-rw---- 1 root disk 8, 1 2008-08-04 12:44 /dev/sda1
> brw-rw---- 1 root disk 8, 3 2008-08-04 13:43 /dev/sda3
> brw-rw---- 1 root disk 8, 5 2008-08-04 12:44 /dev/sda5
sda3 is the partition I used. It is a primary partition.
I belong to the disk group, but I cannot create the volume unless I run 
Scramdisk using sudo.

Nothing is reported to /var/log/messages about the volume creation.

When I kill the stalled mkfs.ext2 process, I briefly see a Scramdisk 
Create dialog showing volume creation 20-30% complete. Then it is 
covered by an error dialog "Couldn't mount device: Invalid argument". If 
I move that aside, I can see the value in the Scramdisk Create dialog 
change to 80% complete. Clicking OK in the error dialog also closes the 
create dialog.

A straight mkfs of an ext2 filesystem on the partition works normally.

Hans-Ulrich Juettner wrote:
> I'm especially worried about the odd observation that scramdisk
> reports the size of the whole drive not of the partition you
> wanted to create the container on. If somehow the device of the
> whole drive has been chosen, a possible reason of the hanging
> might have been that the kernel driver has mounted the device
> read only because of missing access rights. If so, it's very
> odd that the container has been created that far. But in that
> case you have been lucky that the device wasn't overwritten.
>
> In order to further investigate the problem could you please
> check by "ls -l" the access rights of the devices of your whole
> drive and the partition in question. Moreover, it might be
> helpful to have a look at /var/log/messages what the scramdisk
> kernel driver has reported on the event of the failed container
> creation.
>
> Best regards
> Ulrich
>   

Re: [SD4L-user] mkfs hangs when creating large container from HD partition

[Jonathan C. <jco...@ro...>]

Hi Ulrich,

A solution for this problem is not urgent.

The misreporting of partition size occurs when I create a 
Windows-compatible drive, using the defaults:
SHA1 digest, Blowfish cipher, vfat/msdos file system. The same disk 
partition was used.

Thanks.

Hans-Ulrich Juettner wrote:
> Today I've managed to reproduce the problem. It's a deadlock produced
> in some circumstances by scramdisk waiting for the mkfs command to
> finish while the mkfs command is waiting for scramdisk to read it's
> output. The "Couldn't mount device: Invalid argument" is simply an
> aftereffect of the failed mkfs command.
>
> On the other hand, I haven't seen scramdisk reporting the size of
> the whole drive instead of the size of the selected partition, are
> you sure about this? If yes, where exactly have you seen the wrong
> size?
>
> Finally, I'd like to ask whether you have an urgent need for a bug fix
> package. I'm hesitating to publish a complete new bug fix release for
> all the supported distributions since I'm preparing for a major new
> version which, however, will take some months to be finished.
> I could send you a patch for the sources or a package just for your
> distribution. What do you think about that?
>
> Best regards
> Ulrich
>

Re: [SD4L-user] mkfs hangs when creating large container from HD partition

[Hans-Ulrich J. <han...@t-...>]

HI Jonathan,

Jonathan Coles wrote:
> Hi Ulrich,
> 
> A solution for this problem is not urgent.
> 
> The misreporting of partition size occurs when I create a 
> Windows-compatible drive, using the defaults:
> SHA1 digest, Blowfish cipher, vfat/msdos file system. The same disk 
> partition was used.
> 

my question where the misreporting occurs was meant with
respect to the window/process. Meanwhile I've seen it myself.
The container creation dialog reports the size of the partition
but the size of the mounted container is later reported as
the size of the whole disk. Does this match your observation?

Best regards
Ulrich

Re: [SD4L-user] mkfs hangs when creating large container from HD partition

[Jonathan C. <jco...@ro...>]

Yes.

Hans-Ulrich Juettner wrote:
> HI Jonathan,
>
> Jonathan Coles wrote:
>> Hi Ulrich,
>>
>> A solution for this problem is not urgent.
>>
>> The misreporting of partition size occurs when I create a 
>> Windows-compatible drive, using the defaults:
>> SHA1 digest, Blowfish cipher, vfat/msdos file system. The same disk 
>> partition was used.
>>
>
> my question where the misreporting occurs was meant with
> respect to the window/process. Meanwhile I've seen it myself.
> The container creation dialog reports the size of the partition
> but the size of the mounted container is later reported as
> the size of the whole disk. Does this match your observation?
>
> Best regards
> Ulrich
>

Re: [SD4L-user] mkfs hangs when creating large container from HD partition

[Hans-Ulrich J. <han...@t-...>]

Hi Jonathan,

Jonathan Coles wrote:
> Hi Ulrich,
> 
>> $ ls -l /dev/sda*
>> brw-rw---- 1 root disk 8, 0 2008-08-04 12:44 /dev/sda
>> brw-rw---- 1 root disk 8, 1 2008-08-04 12:44 /dev/sda1
>> brw-rw---- 1 root disk 8, 3 2008-08-04 13:43 /dev/sda3
>> brw-rw---- 1 root disk 8, 5 2008-08-04 12:44 /dev/sda5
> sda3 is the partition I used. It is a primary partition.
> I belong to the disk group, but I cannot create the volume unless I run 
> Scramdisk using sudo.
> 

you have no rights to access /dev/sda3 unless you change your
active group to "disk" with the command

newgrp disk

a scramdisk started after that command from the same shell
will create the volume.

> Nothing is reported to /var/log/messages about the volume creation.
> 
> When I kill the stalled mkfs.ext2 process, I briefly see a Scramdisk 
> Create dialog showing volume creation 20-30% complete. Then it is 
> covered by an error dialog "Couldn't mount device: Invalid argument". If 
> I move that aside, I can see the value in the Scramdisk Create dialog 
> change to 80% complete. Clicking OK in the error dialog also closes the 
> create dialog.
> 
> A straight mkfs of an ext2 filesystem on the partition works normally.
> 

Today I've managed to reproduce the problem. It's a deadlock produced
in some circumstances by scramdisk waiting for the mkfs command to
finish while the mkfs command is waiting for scramdisk to read it's
output. The "Couldn't mount device: Invalid argument" is simply an
aftereffect of the failed mkfs command.

On the other hand, I haven't seen scramdisk reporting the size of
the whole drive instead of the size of the selected partition, are
you sure about this? If yes, where exactly have you seen the wrong
size?

Finally, I'd like to ask whether you have an urgent need for a bug fix
package. I'm hesitating to publish a complete new bug fix release for
all the supported distributions since I'm preparing for a major new
version which, however, will take some months to be finished.
I could send you a patch for the sources or a package just for your
distribution. What do you think about that?

Best regards
Ulrich