I tried to change the original sector size on the OLE files(e.g. doc, xls, ppt),
but It is to difficult..
In the documentation, it said that the sector size is 512 bytes.
However, I want to change the size because of my research about document security.
So my question is, "is it possible to reduce the sector size from 512 bytes to
64 bytes or 128 bytes ?"
is your question related to the Microsoft Teams product? Thinking it isn't, so might want to remove that tag. But if it is, are you wanting to reduce sector size of files in the Sharepoint?
You might want to look at StgOpenStorageEx(). You can set the sector size in the STGOPTIONS member, but typically the only valid values I remember were 512 and 4096. Those are probably defined in some header file. The 512 was for the original implementation and then 4096 was added starting with Windows 2000 which allowed more sub storages in the file.
Related
I am trying to use CreateHeap and PlacedResources in DirectX12. However for CreateHeap it requires a D3D12_HEAP_DESC where it says "applications should pass SizeInBytes (a field of the D3D12_HEAP_DESC) values which are multiples of the effective Alignment". And then they go to show an alignment D3D12_DEFAULT_RESOURCE_PLACEMENT_ALIGNMENT #defined as 64KB., where is says 64KB is the alignment.
Does Microsoft DirectX12 use 65536 Bytes as its definition of 64KB or 64000 Bytes (so basically is 1024 or 1000 bytes the definition of KB for microsoft)? I don't want to waste any bytes and I don't know where I can find the definition for these types of units for microsoft. As Wikipedia shows 1024 KB as the legacy unit of KiloByte, so is microsoft standards up to date is the question.
The "Kibi" .vs "Kilo" difference for the SI units is an important one, particularly for fixed-storage sizes. That said, in programming specifications "KB" almost always means "1024 bytes".
If you look in the d3d12.h header, you will see that the value of D3D12_DEFAULT_RESOURCE_PLACEMENT_ALIGNMENT is base-2:
#define D3D12_DEFAULT_RESOURCE_PLACEMENT_ALIGNMENT ( 65536 )
We know the size of sector in disk is 512 bytes. We also know the first sector mainly record MBR and partition table. The size of MBR is 446 bytes and the size of partition table is 64 bytes. But the sum of the size of MBR and partition is 510 bytes isn't equal 512 bytes. What do we use the remaining 2 bytes to do?
The last two bytes are the boot signature. The BIOS is supposed to check that these bytes have values 0x55 and then 0xAA before loading the bootstrap code from sector 0, so this isn't really a Linux question.
https://support.microsoft.com/en-us/kb/149877
Wikipedia has tables for the common layouts, and the last two bytes are used for the "boot signature" (55 AA).
The BIOS is supposed to check this before trying to launch into the booting process.
I've been wandering about the size of bss, data or text that I have. So I typed size command.
The result is
text data bss dec hex filename
5461 580 24 ....
What does the number mean? Is the unit bits, Bytes, Kilobytes or Megabytes?
In addition, how to reduce the size of bss, data, text of the file? (Not using strip command.)
That command shows a list of the sections and their sizes in bytes found in an object file. The unit is decimal bytes, unless display of a different format was specified. And there most likely exists a man page for the size command too.
"reduce the size" - modify source code. Take things out.
As for the part about reducing segment size, you have some leeway in moving parts from data to bss by not initializing them. This is only an option if the program initializes the data in another way.
You can reduce data or bss by replacing arrays with dynamically allocated memory, using malloc and friends.
Note that the bss takes no space in the executable and reducing it just for the sake of having smaller numbers reported by size is probably not a good idea.
I'm writing a perl script that track the output of xentop tool, I'm not sure what is the meaning for VBD_RD & VBD_WR
Following http://support.citrix.com/article/CTX127896
VBD_RD number displays read requests
VBD_WR number displays write requests
Dose anyone know how read & write requests are measured in bytes, kilobytes, megabytes??
Any ideas?
Thank you
As far as I understood, xentop shows you two different measuers (two for read and write).
VBD_RD and VBD_WR's measures are unit. The number of times you tried to access to the block device. This does not say anything about the the number of bytes you have read or written.
The second measure read (VBD_RSECT) and write (VBD_WSECT) are measured in "sectors". You can find the size of the sectors by using xenstore-ls (https://serverfault.com/questions/153196/xen-find-vbd-id-for-physical-disks) (in my case it was 512).
The unit of a sector is in bytes (http://xen.1045712.n5.nabble.com/xen-3-3-testing-blkif-Clarify-units-for-sector-sized-blkif-request-params-td2620172.html).
So if the VBD_WR value is 2, VBD_WSECT value is 10, sector size is 512. We have written 10 * 512 bytes in two different requests (you tried to access to the block device two times but we know nothing about how much bytes were written in each request but we only know the total). To find disk I/O you can periodically check these values and take the derivative between those values.
I suppose the sector size might change for each block device somehow, so it might be worthy to check the xenstore-ls output for each domain but I'm not sure. You can probably define it in the cfg file too.
This is what I found out and understood so far. I hope this helps.
The Linux kernel API has a __bread method:
__bread(struct block_device *bdev, sector_t block, unsigned size)
which returns a buffer_head pointer whose data field contains size worth of data.However, I noticed that reading beyond size bytes still gave me valid data up to PAGE_SIZE number of bytes. This got me wondering if I can presume the buffer_head returned by a *__bread* always contains valid data worth PAGE_SIZE bytes even if the size argument passed to it is lesser.
Or maybe it was just a coincidence.
The __bread perform a read IO from given block interface, but depending on the backing store, you get different results.
For harddrives, the block device will fetch data in sector sizes. Usually this is either 512 bytes or 4K. If 512 bytes, and you ask for 256 bytes, you'll be able to access the last parts of the sector. Thus, you may fetch up to the sector size. However, it is not always true. With memory backed devices, you may only access the 256 bytes, as it is not served up by the block layer, but by the VSL.
In short, no. You should not rely on this feature, as it depends on which block device is backing the storage and may also change with block layer implementation.