qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [QEMU : VVFAT] vvfat.c - help required for understandin


From: Pintu Kumar
Subject: Re: [Qemu-devel] [QEMU : VVFAT] vvfat.c - help required for understanding/modification
Date: Sat, 22 Oct 2011 21:34:53 +0530

Hello Mr. Johannes, Kevin

I already did some work for scanning only top level directory in vvfat.
Using the following logic in read_directory()

if(parent_index >= 0 & (!dot & !dotdot))
{
       free(buffer);
       break;
}

Hope this is correct logic for skipping sub-directories content by
just scanning only dot and dotdot entries inside it.

But as per the recent analysis it was observed that there is some
problem in skipping sub-directory scanning itself.
Because when I issue "df" command on VVFAT partition I get
read_cluster errors during these sector location.

Mr. Johannes, can you clarify on this first.

Then we will look into the dynamic mapping part later.


Thank you very much.


Thanks, Regards,
Pintu


On Thu, Oct 20, 2011 at 1:43 PM, Kevin Wolf <address@hidden> wrote:
> Am 19.10.2011 20:34, schrieb Pintu Kumar:
>> Dear Mr. Johannes,
>>
>> Thank you very much for your reply.
>>
>> So according to you implementing dynamic mapping logic after mounting
>> in VVFAT is possible.
>>
>> But from your following mail, I could not understand how to do that.
>>
>> Can you explain me with reference from the vvfat.c code.
>>
>> What should I do to scan only top level files/folders in read_directory?
>>
>> And what should I need to do in vvfatd_process_req (case : READ) to
>> create dynamic mapping on the fly before displaying the content on
>> guest OS.
>>
>> Right now I very this on my Linux PC it using "ls" command.
>>
>> Example:
>> If my vvfat mount path is /mnt/movifs and it contains one
>> sub-directory say "test1"
>> Then I use "ls -l /mnt/movifs/test1" in which case vvfatd_process_req
>> is invoked and then vvfat_read is invoked.
>>
>>
>> Please let me know.
>
> You asked in a second mail that you sent privately that I explain to you
> how to implement this, as you didn't fully understand what Johannes
> wrote. I'm going to add my reply here so that we don't have several
> separate mail threads. Actually, adding the mailing list wouldn't hurt
> either, but that's your decision.
>
> There's really one main thing that I would recommend you to finally do:
> Take a look at how FAT works. Completely independent of vvfat. And then
> think about how to implement something like this. And only then go back
> to vvfat and do it there. I won't do that for you, even if you double
> the length of the email thread.
>
>>> ---------- Forwarded message ----------
>>> From: Johannes Schindelin <address@hidden>
>>> Date: Wed, Oct 19, 2011 at 1:37 AM
>>> Subject: Re: [QEMU : VVFAT] vvfat.c - help required for
>>> understanding/modification
>>> To: Pintu Kumar <address@hidden>
>>>
>>>
>>> Hi,
>>>
>>> On Sun, 16 Oct 2011, Pintu Kumar wrote:
>>>
>>>> In short, we wanted to implement partial scanning in the beginning and
>>>> dynamic mappings for VVFAT during runtime and after VVFAT is mounted.
>>>> That is, to scan only top level files and directories (skip
>>>> sub-directories content) during vvfat_prepare() and mount it.
>>>>
>>>> Later we a particular sub-directory is accessed by the guest OS, we
>>>> wanted to create its mapping on the fly.
>>>
>>> That sounds doable, since you can initialize the respective blocks in the
>>> FAT lazily, when they are accessed.
>
> I think it's possible in a very limited way. The nasty thing is that you
> don't really have the notion of directories when the guest accesses the
> file system. You have accesses to sectors that contain the FAT.
>
> Once the guest has read in a sector of the FAT, you must consider this
> sector final. You can't later allocate new clusters in this sector of
> the FAT because in general the guest OS will have cached the sector and
> won't reread it.
>
> So the real problem is to manage which clusters already have been read;
> which clusters you already referenced, but are still open for additions;
> and which files/subdirectories still need to be integrated somewhere.
> The guest can read the sectors of the FAT in any order, and it could
> read sectors that you haven't referenced yet at all (because, who reads
> single sectors?), which should add a bit to the fun.
>
>>>> I did some work on it but facing some problem. The sub-directory
>>>> contents are not visible after dynamic mapping and updating the FAT
>>>> content.
>>>>
>>>> I wanted to know your opinion if such kind of logic is possible to
>>>> implement in VVFAT.
>>>
>>> I think the basic problem is to know when to update the FAT content. As I
>>> alluded to above, I would do it thusly: Initialize the top-level directory
>>> and remember the blocks you want to use for the subdirectories. Whenever
>>> the corresponding blocks' contents are requested, initialize them, again
>>> ear-marking blocks for the subdirectories.
>>>
>>> But maybe I misunderstood?
>
> It really boils down to this question: Do we have enough space in the
> FAT for leaving most of it sparse? It looks like we're talking about a
> rather big directory tree, otherwise reading it in on startup wouldn't
> be a problem.
>
> And of course you're wasting precious disk space: If I understand the
> code right we only have 504 MB for the whole file system (should still
> be possible to increase a bit, but at some point you'll need FAT32). The
> available space will be reduced by same percentage as FAT entries stay
> unused.
>
> Kevin
>



reply via email to

[Prev in Thread] Current Thread [Next in Thread]