Could someone explain me the answer to this. I got this in a quiz and couldn't answer it.
Assume that
All blocks in a disk are of size 4KB (4096 bytes).
The top level of an inode is stored in a disk block of size 4KB.
All file attributes, except data block locations, take up a total of
128 bytes (out of the above 4KB).
Each direct block address takes up 8 bytes of space and gives the
address of a disk block of size 4KB.
Last three entries of the first level of the inode point to single,
double, and triple indirect blocks respectively.
Question: What is the largest size of a file that can be accessed through direct block entries of the inode?
The calculations are quite simple:
(( 4096 − 128 ) / 8 − 3) × 4096 = 2019328
Related
For a I feel like it would be 63504 Bytes because the file size would be (496/4)*512 + 16 Bytes.. But I cant seem to get that in the requested format, which leads me to believe that I attempted it wrong.
For pt b I have no Idea how to approach it.. Any help/hints would be appreciated
Part [a]
Starting with
Extent size 1 ==> File size will be 2^0 * 512 bytes
Extent size 2 ==>File size will be 2^1 * 512 bytes
Extent size 3 ==>File size will be 2^2 * 512 bytes
......
Extent size 12 ==>File size will be 2^11 * 512 bytes
Extent size x ==>File size will be 2^(x-1) * 512 bytes
Part [b]
Considering 512 bytes as block size,
Number of disk accesses required for getting 1,00,000 byte will be,
100000/512 = 196
I hope it does make sense to you....
I'm making a project about a digital recorder trough microcontroller. I want to store a voice recorded from microphone and build a .WAV file. I have the captured voice samples from ADC, and I only know the structure of WAV file (from this image), but I don't know anything else of it. Could you help me, giving me some information about the building process of this file type?
Thank you.
Now I can explain how I making the code. Maybe for someone few part of this explanation may result redundant, but I want to say clearly every pass I did'nt understand.
For first, I wanna explain very single stack of the hader of .wav file, referred in the image I posted upward.
The first segment , ChunkID, is simply a char vector "RIFF".
The second segment, ChunkSize, is the size from this point to the end of file; because the first 2 segment are 8 byte, the value of this segment is simple the total size of file (in byte) - 8 byte. Note that in a variabile-time recording this value is not known at this point, so for first time this is filled by a casual value, and at the end of recording, when the total size of file is known, it will filled with correct value.
Segment Format is a char vector "WAVE".
The segment Subchunk1D is char vector "fmt " (put attention at the final space).
The segment subchunk1size is 16 (decimal value).
The AudioFormat segment is 2 byte, in my case is 1 for the PCM.
The NumChannel segment is 2 byte, and its value is 1 for mono and 2 for stereo.
The SampleRate segment is the sample frequency in Hz (e.g. 44100).
ByteRate segment is given by ByteRate = SampleRate * BlockAlign.
BlockAlign segment is given by BlockAlign = NumChannels * BitPerSample / 8.
BitPerSample segment is the number of bit that compose each sample. In my case of a 10-bit ADC , I have casted this value to 8 bit, losing the less significant 2 bit.
Subchunk2ID segment is a char vector "data".
Subchunk2Size segment contains the entire size of the data acquired (sampples), and so it is the entire size of the file - 44, because 44 is the byte count from begin to this point. Another method tho calculate this value is: Subchunk2Size = NumSample * BlockAlign. In any case, this segment is not known at this point, and for its calculation it needs the end of recording.
The final segment, data, is the vector that contain the sample. Is the only doesn't have a fixed dimension (of course).
Each segment described is in succession, without any gender of delimiter, because the delimiter is intrinsec in the dimension of each segment.
Implement this in C is very simple, if each segment is well described.
I have a pointer to a process that is running. I want to know how much of the total physical memory is that process taking up.
I tried this but I am getting 0 as a return value.
unsigned long mem_usage(struct task_struct *process)
{
return process->mm->total_vm/2048 * 100000; // this is wrong vm means virtual memory.
}
process->mm->total_vm returns bytes right? Is there an easier way to calculate this?
According to mm_types.h
unsigned long total_vm; /* Total pages mapped */
is the size in pages.
This means, if you want the size in bytes, you have to convert the pages to bytes
total_vm << PAGE_SHIFT
Update:
The reverse way, converting bytes to pages, is
pages = bytes >> PAGE_SHIFT;
But this works only for full pages. If bytes is some pages plus some remaining bytes, you must either increment the number of pages or
pages = (bytes + PAGE_SIZE - 1) >> PAGE_SHIFT;
For just 2 GiB this would be
pages_2gb = (2 * 1024 * 1024 * 1024) >> PAGE_SHIFT;
I am preparing for an upcoming exam and I was having trouble with this problem:
direct mapped cache of size 64K with block size 16 bytes. Cache starts empty
What is the cache miss rate if...
ROWS = 128, COLS = 128
ROWS = 128 and COLS = 192
ROWS = 128 and COLS = 256
[solution: page 5 http://www.inf.ethz.ch/personal/markusp/teaching/263-2300-ETH-spring11/midterm/midterm.pdf ]
I was confused about how they got "the cache stores 128 x 128 elements". I thought the cache size was 64K (2^16).
Also, can someone explain how to approach each question? My professor had some formula to calculate the number of accesses in each block: block size/stride, but it doesn't seem to work here.
As far as I understand; in case 1, both src and dst matrices are of 64kb size (128 * 128 * 4 bytes); since the cache is directly mapped and has a size of 64kb; the entries of src & dst of the same indexes will have to be mapped to the same location in the cache (since (0+i mod)64 = (64+i mod)64) at the same time to be used in the line
dest[i][j]=src[i][j]
Therefore you have 100% miss rate; The same is applied to case 3 since the new size is a multiple of 64kb (128 * 256 * 4), so it doesn't make any difference;
But for case 2; the size of the matrices becomes 96 kb (128 * 192 *4 bytes); so now both src & dst may be loaded at the same time and you will have a lower miss rate.
Where does the 2048 number comes from in is the problem?
Consider a file system that uses inodes to represent files. Disk blocks are 8 KB in size and a pointer to a disk block requires 4 bytes. This file system has 12 direct disk blocks, as well as single, double, and triple indirect disk blocks. What is the maximum size of a file that can be stored in this file system?
(12 * 8 KB) + (2048 * 8 KB) + (2048 * 2048 * 8 KB) + (2048 * 2048 * 2048 * 8 KB) = 64 terabytes
I was thinking 8KB/4B, but isn't that 2000? 8000/4.
Sometimes when discussing numbers in the context of computers, kB = 1024 bytes, MB = 1,048,576 bytes, etc.
In this case, 8kB = 8192 bytes. 8192 / 4 = 2048.
2048 is 8K (the block size) divided by 4 (the size of a pointer).
You need to allocate an entire 8192-byte block of pointers to 8K blocks; you can fit 2048 pointers into one of these.
Further, you can fit 2048 pointers to blocks of pointers to block for additional 2048 * 2048 * 8 KB capacity, and then 2048 * 2048 * 2048 * 8 KB of pointers to blocks of pointers to blocks of pointers to 8K blocks.
If you think that it goes a little like a cumulative tale, you're not alone.