I own a SonyEricsson Xperia X1.
According to SKTools Main Storage is formated this way:
It has sectors with 2048 bytes size and 2048 bytes cluster size. So 1 sector per cluster. Also it is formated in FAT32.
On the other hand Storage Card has 512 bytes sector size and 4096 bytes cluster size. So 8 Sector per cluster. Also FAT32.
512 bytes sector is the norm for HardDiskDrives as well. Optical Disk Drives have 2048 bytes sector (i think).
There is going to be a move to 4096 bytes sector for HDDs starting January 2011, which gives more free space and more speed.
Could we do something like that for our phones? 4096 byte sectors and 4096 bytes clusters?
I guess storage cards are diferent Memory arrangements... we have many tweaks to have bigstorage ROMS, search and read bud
Related
Hi All,
I have been trying to find the best way to configure my swap for my android phone, currently the G1. I had started out with the regular swap partition but find my phone performance degraded over time thus I decided to test the usual read/write for my Class 6 Micro SDHC card.
Configure the SD card via fdisk and setup 3 partitions (like everyone else).
Command (m for help): p
Disk /dev/sdm: 8166 MB, 8166309888 bytes
224 heads, 56 sectors/track, 1271 cylinders
Units = cylinders of 12544 * 512 = 6422528 bytes
Disk identifier: 0x3114df25
Device Boot Start End Blocks Id System
/dev/sdm1 1 800 5017572 c W95 FAT32 (LBA)
/dev/sdm2 801 1100 1881600 83 Linux
/dev/sdm3 1101 1271 1072512 82 Linux swap / Solaris
Command (m for help): w
The partition table has been altered!
Calling ioctl() to re-read partition table.
WARNING: If you have created or modified any DOS 6.x
partitions, please see the fdisk manual page for additional
information.
Syncing disks.
Afterward, format the drive as vfat, ext3, swap
localhost ~ # mkfs.vfat /dev/sdm1
mkfs.vfat 3.0.1 (23 Nov 2008)
localhost ~ # mkfs.ext3 /dev/sdm2
mke2fs 1.41.3 (12-Oct-2008)
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
117600 inodes, 470400 blocks
23520 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=482344960
15 block groups
32768 blocks per group, 32768 fragments per group
7840 inodes per group
Superblock backups stored on blocks:
32768, 98304, 163840, 229376, 294912
Writing inode tables: done
Creating journal (8192 blocks): done
Writing superblocks and filesystem accounting information: done
This filesystem will be automatically checked every 26 mounts or
180 days, whichever comes first. Use tune2fs -c or -i to override.
localhost ~ # mkswap /dev/sdm3
Setting up swapspace version 1, size = 1072508 KiB
no label, UUID=2046ef6b-ac5a-47a2-9484-ea2a356cc7fa
now the read performance via "hdparm -t /dev/sdxxx"
sdm1 (fat) = Timing buffered disk reads: 26 MB in 3.12 seconds = 8.34 MB/sec
sdm2 (ext3) = Timing buffered disk reads: 26 MB in 3.11 seconds = 8.35 MB/sec
sdm3 (swap) = Timing buffered disk reads: 26 MB in 3.08 seconds = 8.45 MB/sec
as you can see, reading is more or less the same across the board.
now the fun part of write. for fat and ext3, I decided to write to a file, for the swap partition, I decided to write directly to the partition.
FAT:
localhost ~ # dd count=30 bs=1M if=/dev/urandom of=sdm1/test.write
30+0 records in
30+0 records out
31457280 bytes (31 MB) copied, 4.9464 s, 6.4 MB/s
EXT3:
localhost ~ # dd count=30 bs=1M if=/dev/urandom of=sdm2/test.write
30+0 records in
30+0 records out
31457280 bytes (31 MB) copied, 4.94644 s, 6.4 MB/s
SWAP:
localhost ~ # dd count=30 bs=1M if=/dev/urandom of=/dev/sdm3
30+0 records in
30+0 records out
31457280 bytes (31 MB) copied, 8.79714 s, 3.6 MB/s
As you can see, write to a FAT or EXT3 partition seems to be faster than writing to a swap partition. Of course, this is assuming I have done my test correctly . If writing to FAT or EXT3 is faster and reads are the same, would it mean that you get better SWAP performance via a swap file on an EXT3 partition?
thanx for the interesting read
Your write test is flawed.
Flaw 1: You use /dev/urandom as a data source. Data generation from /dev/urandom is heavily affected by CPU usage AND by available entropy -- though it doesn't block, its speed does vary drastically.
Flaw 2: You only run the test ONCE. This means that issues from flaw 1 are totally visible rather than being averaged out over a large number of tests. You should do the test 100's of times and take the average over them.
Flaw 3: Implementation of the ext3 filesystem tend to hide the effects of disk latency. There are caches and journals that you haven't accounted for. In order to get the ACTUAL time that it takes to write to the ext3 filesystem, you need to follow the write test by a synchronization, which will *actually* write the data to the disk (i.e., it will BLOCK until the write is actually completed). Unfortunately though, this test will also synchronize OTHER write operations that are buffered, which will further skew your results. What you REALLY need to do is perform the tests on a completely empty partition. Should be starting sync, begin time, test write, finishing sync, finishing time. Elapsed time = finishing time - begin time.
In other words, I'm sorry, but your conclusions are not correct. What I *very strongly* suspect, is that if you do your tests correctly, you will find that the performance of swap-on-ext3 will actually be *lower* than swap-on-partition due to the extra overhead of the ext3 filesystem.
Note: the linux vfat filesystem implementation also buffers writes.
A little bit of fun trivia:
Back in the days when we actually used floppy disks, you could actually copy an entire disk worth of data over to a vfat floppy disk without it even BEGINNING to write to the disk. Usually, it would begin writing several seconds after the copy "completed". If you wanted to speed it along, a sync or umount would force the buffer immediately to write to disk.
ahhh...thanks for the info. I guess with buffer, it makes timing or calculating the write speed a bit difficult. I will have to think more about this.
This really makes me wonder how do SD card manufactures test their write speed and assign the card class.
I believe they do a test similar to yours without any buffering and write different amounts of data to simple file systems.
Then, according to http://en.wikipedia.org/wiki/Secure_Digital the class number is equal to the amount of minimum write megabytes per second that can be written to the disk when in a clean and unfragmented state. So a class 6 card would at it's slowest writing speed on a perfectly setup disk be able to write data at 6 megabytes per second or faster. Read speed isn't taken into account for the rating, but is generally faster than write speed.
I redid my test with raw write via if=/dev/zero and the write speed is now on-par with what was classified on the SD class. (7.4MBps write on my class 6). Playing around w/ the setting more, seems like the over-time degradation seems to be caused by my swappiness configuration.
So I was transferring some files to the large internal sdcard, when my computer keeled over from a sudden and unanticipated hardware failure. I unplugged the phone immediately and waited for the Media scanning to finish, and waited, and waited. So I shut down the phone, which may in retrospect have been a mistake.
Now the internal sdcard is bizarrely named "_PNG []-1" and Media scanning is currently hung after reattempting the file transfer (begun at 9:58 and still going).
Any advice on steps I should take in attempting to remedy the situation is greatly appreciated.
Magicked from my Vibrant by tube traversing XDA elves.
Well, I used the disktype utility and discovered that the internal memory is fat32. So I ran
Code:
dosfsck -vV /dev/sdc
and got the following for my trouble
Code:
dosfsck 3.0.9 (31 Jan 2010)
dosfsck 3.0.9, 31 Jan 2010, FAT32, LFN
Checking we can access the last sector of the filesystem
Boot sector contents:
System ID "android "
Media byte 0xf0 (5.25" or 3.5" HD floppy)
512 bytes per logical sector
32768 bytes per cluster
32 reserved sectors
First FAT starts at byte 16384 (sector 32)
2 FATs, 32 bit entries
1675264 bytes per FAT (= 3272 sectors)
Root directory start at cluster 2 (arbitrary size)
Data area starts at byte 3366912 (sector 6576)
418713 data clusters (13720387584 bytes)
16 sectors/track, 4 heads
0 hidden sectors
26804208 sectors total
Starting check/repair pass.
Checking for unused clusters.
Checking free cluster summary.
Starting verification pass.
Checking for unused clusters.
/dev/sdc: 32571 files, 130173/418713 clusters
Of course in spite of this happy results, Media scanning continues to hang. (I gave it a half hour before I plugged it in again to run this test, so... I don't think it was gonna snap out of it).
Not really big news for anyone who's installed SDE and poked around a bit, but I thought I'd post this anyway.
Taken from a 16GB Archos 101. Your results may differ.
Code:
Disk /dev/mmcblk0: 536 MB, 536870912 bytes
4 heads, 16 sectors/track, 16384 cylinders
Units = cylinders of 64 * 512 = 32768 bytes
Device Boot Start End Blocks Id System
/dev/mmcblk0p1 5 1605 51200+ 83 Linux
/dev/mmcblk0p2 1605 5511 125023 83 Linux
/dev/mmcblk0p3 5512 6489 31296 83 Linux
/dev/mmcblk0p4 6490 16384 316640 83 Linux
Disk /dev/mmcblk1: 15.3 GB, 15388901376 bytes
4 heads, 16 sectors/track, 469632 cylinders
Units = cylinders of 64 * 512 = 32768 bytes
Device Boot Start End Blocks Id System
/dev/mmcblk1p1 1 469632 15028216 c Win95 FAT32 (LBA)
Being MMC rather than MTD devices, it ought to be possible to repartition to shuffle some space around, perhaps gaining as much as 50MB extra space for /data.
Additionally, for custom firmwares maybe even repartitioning mmcblk1 may be possible, to create an alternate partition to mount /data/ to.
Of course, for fear of ruining my 101 I have only used fdisk for read-only operations.
don't forget mmcblk2..
it's the external sdcard
Of course I was examining the internal flash storage of the device.
Having my 101 for just under 3 weeks I'm not quite brave enough to repartition mmcblk0, as it would be very difficult to recover an operational system if this were to not go as well as expected. :>
I'm hoping that someone with a little more insight or perhaps a little braver than I could chime in on the possibility.
why won't you repartition (shrink p1 and append other partitions) blk1? (8 / 16 GB storage)
don't touch blk0 when you don't have to
chulri said:
why won't you repartition (shrink p1 and append other partitions) blk1? (8 / 16 GB storage)
don't touch blk0 when you don't have to
Click to expand...
Click to collapse
This was of course my suggestion for alternate firmwares that can take advantage of this.
Moved to general as not android development
In case this info is of use to someone...
Trying to understand what goes where,
Here is the partition table of a U8800:
#######################################
Disk /dev/sdb: 3959 MB, 3959422976 bytes
1 heads, 62 sectors/track, 124729 cylinders, total 7733248 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000000
Device Boot Start End Blocks Id System
/dev/sdb1 1 491520 245760 b W95 FAT32
/dev/sdb2 * 491521 492520 500 4d QNX4.x
/dev/sdb3 492521 498520 3000 46 Unknown
/dev/sdb4 498521 7733247 3617363+ 5 Extended
/dev/sdb5 524288 548863 12288 59 Unknown
/dev/sdb6 655360 921599 133120 4c Unknown
/dev/sdb7 1048576 1049575 500 5a Unknown
/dev/sdb8 1179648 1185791 3072 58 Unknown
/dev/sdb9 1310720 1324719 7000 50 OnTrack DM
/dev/sdb10 1441792 1447935 3072 4a Unknown
/dev/sdb11 1572864 1579007 3072 4b Unknown
/dev/sdb12 1703936 2154495 225280 83 Linux
/dev/sdb13 2228224 3457023 614400 83 Linux
/dev/sdb14 3538944 7733247 2097152 69 Unknown
#############################################
sdb1: This is the FAT32 partition that gets mounted when we boot into pink screen;
It holds, among other files, EMMCBOOT.MBN, which, if not present and as far as I've experimented, will get the phone straight into a blue screen and initiate a flash procedure if a 'dload' folder with a ROM is found in the sdcard. The contens of this partition are changed when a ROM is flashed.
sdb2: Is flagged as bootable, and holds an (so far) unknown filesystem (if any; could hold a raw binary image, for instance);
sdb3: Holds an unknown filesystem, if any. This partition is changed whenever you flash a ROM. dumping this partition back, from any 2.3BETA, to a 2.3 (B522) running phone, will get the USB pink screen mode working again, allowing acces to sdb1.
sdb5: holds an unknown filesystem if any; dumping this one back gets us the original "IDEOS" logo and, probably, whatever is needed to make previous CWM backups work again.
sdb6: ext3 filesystem with a directory called "recovery".
sdb7: Unknown filessytem, if any.
sdb8: Unknown filesystem, if any.
sdb9: Unknown filesystem, if any.
sdb10: Unknown filesystem, if any.
sdb11: Unknown filesystem, if any.
sdb12: ext3 filesystem; gets mounted at "/system".
sdb13: ext3 filesystem; gets mounted at "/data".
sdb14: vfat filesystem; represents the internal sdcard.
I'm trying to find out what needs to be restored in order to perform a clean, reliable downgrade. sdb5 is a must, but not the only one. I've flashed 2.2 and dumped it back right after. The result is an almost downgraded U8800. I say almost because charging the battery while the phone is off shows a different image (the one that comes with 2.3) and I can't power up the phone unless I take the cable out; this means there are still remnants of 2.3 somewhere...
UPDATE: Not being able to power up the phone was to due to the CWM recovery; restoring original recovery.img solved that one.
I have an Nvdia shield pro 500gb which I would like to upgrade to a 1tb using linux ubuntu but I can't seem to figure It out. I have a Samsung 1tb evo 870
Click to expand...
Click to collapse
Old Drive
Disk /dev/sdc: 465.78 GiB, 500107862016 bytes, 976773168 sectors
Disk model: ASM1156-PM
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 33553920 bytes
Disklabel type: dos
Disk identifier: 0x0596bb2c
My SSD Info
Disk /dev/sdj: 931.53 GiB, 1000204886016 bytes, 1953525168 sectors
Disk model: ASM1156-PM
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 33553920 bytes
Disklabel type: dos
Disk identifier: 0x0596bb2c
steps I took
old Drive
dd if=/dev/sdc of=firstpart.bin count=6899870
dd if=/dev/sdc bs=512 skip=976773158 of=lastpart.bin
./shield_pro_new_disk_gpt_calculator-0.3 lastpart.bin 1000204886016 new_lastpart.bin
New Drive
sudo dd if=firstpart.bin of=/dev/sdj
sudo dd if=new_lastpart.bin of=/dev/sdj bs=512 seek=1953525158
Here.
Daniam75 said:
Here.
Click to expand...
Click to collapse
Hey Daniam75, can you tell me what I'm doing wrong or can you send me files already working?
Hey did you ever figure this out? I have a pro that I'm trying to put a 1tb ssd in also. I followed the steps on the here link. But it won't boot. Just powers up and sits there w no image