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