I am using Yocto and meta-atmel to build an embedded Linux(4.4.19). On my board is an Flash which is connected through SPI.
I tried several ways to write on it. But they all failed.
How to read/write data into it?
Some info:
Flashtype 4Mbit:
s25fl164k (http://www.farnell.com/datasheets/1756778.pdf)
Included through Device Tree:
spi1: spi#f8008000 {
cs-gpios = <&pioC 25 GPIO_ACTIVE_HIGH>;
status = "okay";
m25p80#0 {
compatible = "spansion,s25fl164k";
spi-max-frequency = <50000000>;
reg = <0>;
};
};
Kernel config:
MTD devices activated
SPI activated
SPI device driver activated
dmesg print at startup:
[ 2.630000] Creating 8 MTD partitions on "atmel_nand":
[ 2.640000] 0x000000000000-0x000000040000 : "bootstrap"
[ 2.640000] 0x000000040000-0x0000000c0000 : "uboot"
[ 2.650000] 0x0000000c0000-0x000000100000 : "env"
[ 2.660000] 0x000000100000-0x000000140000 : "env_redundant"
[ 2.660000] 0x000000140000-0x000000180000 : "spare"
[ 2.670000] 0x000000180000-0x000000200000 : "dtb"
[ 2.670000] 0x000000200000-0x000000800000 : "kernel"
[ 2.680000] 0x000000800000-0x000010000000 : "rootfs"
[ 2.690000] atmel_spi f0004000.spi: version: 0x213
[ 2.690000] atmel_spi f0004000.spi: DMA TX channel not available, SPI unable to use DMA
[ 2.700000] atmel_spi f0004000.spi: Atmel SPI Controller using PIO only
[ 2.700000] atmel_spi f0004000.spi: Atmel SPI Controller at 0xf0004000 (irq 25)
[ 2.710000] m25p80 spi32766.0: at25df321a (4096 Kbytes)
fdisk print (look at mtdblock8):
root#sama5d3xek:~# fdisk -l
Disk /dev/ram0: 8 MiB, 8388608 bytes, 16384 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk /dev/ram1: 8 MiB, 8388608 bytes, 16384 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk /dev/ram2: 8 MiB, 8388608 bytes, 16384 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk /dev/ram3: 8 MiB, 8388608 bytes, 16384 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk /dev/mtdblock0: 256 KiB, 262144 bytes, 512 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 /dev/mtdblock1: 512 KiB, 524288 bytes, 1024 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 /dev/mtdblock2: 256 KiB, 262144 bytes, 512 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 /dev/mtdblock3: 256 KiB, 262144 bytes, 512 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 /dev/mtdblock4: 256 KiB, 262144 bytes, 512 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 /dev/mtdblock5: 512 KiB, 524288 bytes, 1024 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 /dev/mtdblock6: 6 MiB, 6291456 bytes, 12288 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 /dev/mtdblock7: 248 MiB, 260046848 bytes, 507904 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 /dev/mtdblock8: 4 MiB, 4194304 bytes, 8192 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 /dev/mmcblk0: 7.4 GiB, 7985954816 bytes, 15597568 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
Disklabel type: dos
Disk identifier: 0x00000000
Device Boot Start End Sectors Size Id Type
/dev/mmcblk0p1 8192 15597567 15589376 7.4G b W95 FAT32
Reading/writing test:
cat /dev/mtdblock8
echo "hello" > /dev/mtdblock8
cat /dev/mtdblock8
I don't get any results/errors.
Mounting:
mkdir /tmp/abc
mount -t jffs2 /dev/mtdblock8 /tmp/abc
mount: /dev/mtdblock8: can't read superblock
Any ideas?
I like to do a demo. Let's say write "hello Linux" on position 12345 at the SPI flash.
Perhaps the device is locked by U-Boot, and ioctl UNLOCK is not implemented in your kernel's m25p80 driver. I've seen that before, refer to erasing-flash-nor-ioctlmemunlock-return-status.
You can use Memory technology Devices (MTD) subsystem for erase/write/read operation on flash partitions.
The SPI flash is mounted to mtdblock8 in your case.Use the below command to see all the existing partitions
cat /proc/mtd
To write to the mtd device, use nandwrite command. It is available with busybox.
For mounting try
mount -t jffs2 /dev/block/mtdblock8 /tmp/abc
Details on MTD:
http://free-electrons.com/blog/managing-flash-storage-with-linux/
Details on mtd utils:
http://processors.wiki.ti.com/index.php/Mtdutils
So, let's go step by step. Your SPI NOR flash is described in the devicetree, and it seems you've managed to configure your kernel correctly (that is, add the relevant drivers). This is confirmed by your log:
[ 2.710000] m25p80 spi32766.0: at25df321a (4096 Kbytes)
It would also seem true that /dev/mtd8 is the MTD device associated with that device (from your size analysis). You should be able to confirm it by inspecting /sys/class/mtd.
Now, in order to program the device you need to 1) erase the sectors you want to write, 2) write those sectors, and finally read back and confirm.
To write, you can use a write() syscall (i.e. cat somefile > /dev/mtd8). To erase you need an ioctl syscall, i.e. flash_erase command.
The MTD website has some relevant information:
http://www.linux-mtd.infradead.org/index.html
The Free-Electrons post mentioned in hashdefine reply is fine too.
There was an error in my device tree table file. The spi1, the image sensor interface(isi1) and the i2c(i2c1) where using the same pins. When compiling the kernel + dts there are no error shown.
In general the combination of fdisk + mtd_debug was very useful to check the driver and the hardware at low level. In my case SAMA5D35 + own mainboard # dts:
ahb {
apb {
spi1: spi#f8008000 {
cs-gpios = <&pioC 25 GPIO_ACTIVE_LOW>;
status = "okay";
m25p80#0 {
compatible = "spansion,s25fl132k", "jedec,spi-nor";
spi-max-frequency = <108000000>;
reg = <0>;
m25p,fast-read;
};
};
// conflicts with spi1
i2c1: i2c#f0018000 {
status = "disabled";
};
// confilcts with spi1 (pin PC27 periph B TWCK1 pin, conflicts with SPI1_NPCS2, ISI_D10)
isi: isi#f0034000 {
status = "disabled";
};
};
now it works fine
You can use mtd_debug command tool. With this tool is possible to test read/write one byte. This is very convenient to localize problem.
You can try lower clock frequency, this solve my problems with SPI FLASH:
spi-max-frequency = <10000000>
Related
I have a buildroot system, which mounts ubi ok in linux, but in u-boot I get error 22
When starting in linux this is in dmesg:
ubi0: scanning is finished
ubi0: attached mtd2 (name "rootfs", size 32 MiB)
ubi0: PEB size: 131072 bytes (128 KiB), LEB size: 126976 bytes
ubi0: min./max. I/O unit sizes: 2048/2048, sub-page size 2048
ubi0: VID header offset: 2048 (aligned 2048), data offset: 4096
ubi0: good PEBs: 256, bad PEBs: 0, corrupted PEBs: 0
ubi0: user volume: 1, internal volumes: 1, max. volumes count: 128
ubi0: max/mean erase counter: 2/0, WL threshold: 4096, image sequence number: 894512245
ubi0: available PEBs: 0, total reserved PEBs: 256, PEBs reserved for bad PEB handling: 40
ubi0: background thread "ubi_bgt0d" started, PID 1103
--
UBIFS (ubi0:0): UBIFS: mounted UBI device 0, volume 0, name "rootfs", R/O mode
UBIFS (ubi0:0): LEB size: 126976 bytes (124 KiB), min./max. I/O unit sizes: 2048 bytes/2048 bytes
UBIFS (ubi0:0): FS size: 25649152 bytes (24 MiB, 202 LEBs), journal size 4444160 bytes (4 MiB, 35 LEBs)
UBIFS (ubi0:0): reserved for root: 0 bytes (0 KiB)
UBIFS (ubi0:0): media format: w4/r0 (latest is w4/r0), UUID 29B5D4CF-8B0B-465A-8D03-F3A464E6250E, small LPT model
UBIFS (ubi0:0): full atime support is enabled.
VFS: Mounted root (ubifs filesystem) readonly on device 0:13.
in u-boot mtd returns:
device nand0 <nand0>, # parts = 4
#: name size offset mask_flags
0: u-boot 0x00200000 0x00000000 0
1: kernel 0x01e00000 0x00200000 0
2: rootfs 0x02000000 0x02000000 0
3: user 0x0c000000 0x04000000 0
active partition: nand0,0 - (u-boot) 0x00200000 # 0x00000000
defaults:
mtdids : nand0=nand0
mtdparts: mtdparts=nand0:0x200000#0x0(u-boot),0x1e00000#0x200000(kernel),0x2000000#0x2000000(rootfs),-(user)
but when it try to attach:
=> ubi part rootfs
ubi0: attaching mtd1
UBI init error 22
It's on an embedded system which uses older versions U-Boot 2016.11 and Linux/arm 4.4.289 Kernel
I suppose some parameter is wrong somewhere, can somebody give me some advise where to look?
I have an embedded Linux board with 16Go eMMC flash.
When I boot the image and I run fdisk -l I get this:
root#menzu:~# fdisk -l
Disk /dev/mmcblk2: 14.62 GiB, 15678308352 bytes, 30621696 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
Disklabel type: dos
Disk identifier: 0xe00e5569
Device Boot Start End Sectors Size Id Type
/dev/mmcblk2p1 * 16384 186775 170392 83.2M c W95 FAT32 (LBA)
/dev/mmcblk2p2 196608 9177991 8981384 4.3G 83 Linux
As you can see, my eMMC /dev/mmcblk2 has 14.62 Gb size.
But, my Linux rootfs partiton has only 4.3G,
How can I extend its size at runtime to be 10Gb or 12Gb for example?
I tried resize2fs /dev/mmcblk2p2 but it changed the blocks size to 1K and after that it only shows:
root#menzu:~# resize2fs /dev/mmcblk2p2
resize2fs 1.45.3 (14-Jul-2019)
The filesystem is already 1122673 (4k) blocks long. Nothing to do!
I can force the Yocto build to be 12Go, but that's not a good solution cuz the image will be large.
You need to change the size of your partition with fdisk before using resize2fs: delete the current partition and create a new one that starts at the same block as the one you deleted.
For example:
$ fdisk /dev/mmcblk1
Welcome to fdisk (util-linux 2.34).
Changes will remain in memory only, until you decide to write them.
Be careful before using the write command.
Command (m for help): p
Disk /dev/mmcblk1: 27.86 GiB, 29896998912 bytes, 58392576 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
Disklabel type: dos
Disk identifier: 0x35a60061
Device Boot Start End Sectors Size Id Type
/dev/mmcblk1p1 * 16384 186775 170392 83.2M c W95 FAT32 (LBA)
/dev/mmcblk1p2 196608 7071881 6875274 3.3G 83 Linux
Command (m for help): d
Partition number (1,2, default 2): 2
Partition 2 has been deleted.
Command (m for help): p
Disk /dev/mmcblk1: 27.86 GiB, 29896998912 bytes, 58392576 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
Disklabel type: dos
Disk identifier: 0x35a60061
Device Boot Start End Sectors Size Id Type
/dev/mmcblk1p1 * 16384 186775 170392 83.2M c W95 FAT32 (LBA)
Command (m for help): n
Partition type
p primary (1 primary, 0 extended, 3 free)
e extended (container for logical partitions)
Select (default p): p
Partition number (2-4, default 2): 2
First sector (2048-58392575, default 2048): 196608
Last sector, +/-sectors or +/-size{K,M,G,T,P} (196608-58392575, default 58392575):
Created a new partition 2 of type 'Linux' and of size 27.8 GiB.
Partition #2 contains a ext4 signature.
Do you want to remove the signature? [Y]es/[N]o: N
Command (m for help): p
Disk /dev/mmcblk1: 27.86 GiB, 29896998912 bytes, 58392576 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
Disklabel type: dos
Disk identifier: 0x35a60061
Device Boot Start End Sectors Size Id Type
/dev/mmcblk1p1 * 16384 186775 170392 83.2M c W95 FAT32 (LBA)
/dev/mmcblk1p2 196608 58392575 58195968 27.8G 83 Linux
Command (m for help): w
The partition table has been altered.
Syncing disks.
After that you need to reboot and run resize2fs.
We are getting very frequently below message in /var/log/messages
kernel: SLUB: Unable to allocate memory on node -1 (gfp=0x8020)
In some cases followed by an allocation table
kernel: cache: sigqueue(12019:454c4ebd186d964699132181ad7367c669700f7d8991c47d4bc053ed101675bc), object size: 160, buffer size: 160, default order: 0, min order: 0
kernel: node 0: slabs: 57, objs: 23313, free: 0
kernel: node 1: slabs: 35, objs: 14315, free: 0
Ok, free is 0, but how may this be tuned?
Following is set information
OS - Centos7.3
Kernel - 3.10.0-327.36.3.el7.x86_64
Docker - 1.12.6
Kubernetes - 1.5.5
We have private cloud powered by kurbernetes, having 10 nodes; it was working fine till last month and now we are getting these alerts very frequently on every nodes, pods/container also increased in last few days.
We have enough memory and cpu available on each node.
Any fine tuning for these alert will be very helpful.
Additional information:
sysctl.conf options
net.ipv4.tcp_timestamps = 0
net.ipv4.tcp_max_syn_backlog = 4096
net.core.somaxconn = 1024
net.ipv4.tcp_syncookies = 1
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
net.core.rmem_default = 65535
net.core.wmem_default = 65535
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 65536 16777216
net.ipv4.ip_local_port_range = 1024 65535
vm.max_map_count = 262144
vm.swappiness=10
vm.vfs_cache_pressure=100
Please look at this: https://pingcap.com/blog/try-to-fix-two-linux-kernel-bugs-while-testing-tidb-operator-in-k8s/. It's a kernel bug.
problems seems to be with kernel, first a fall check whether swap memory is properly allocated or not by free -m and mkswap -c, if swap is not properly allocated, do it. if swap is fine, then you might need to update the kernel.
purpose :i want to get information like iostat command can get .
I have already known that if open /proc/diskstats or /sys/block/sdX/stat there are information that :sectors read and sectors write. So if i want to get read/write bytes/s ,the following formula is right ?
read/write bytes per second:
(sectors read/write(now)-sectors read/write(last))*512 bytes/time interval
read /write operations per second :
(read/write IOs(now)+read/write merges(now)-read/write IOs(last)-read/write merges(last ))/time interval
So if i have a timer that every second control software read the information from those two files ,and then using the above formula to calculate the value .Can i get the correct answer ?
TLDR Sector is 512 bytes (octets; 1 sector is 512 bytes; each bytes is 8 bits; every bit is either 0 or 1, but not superposition of them).
"The standard sector size of 512 bytes for magnetic disks was established ....[dubious – discuss] " (c) wiki https://en.wikipedia.org/wiki/Disk_sector
How to check sector size for io statistics (in /proc) in linux:
Check how iostat tool works (it shows kilobyte per second when started as iostat 1) - it is part of sysstat package:
https://github.com/sysstat/sysstat/blob/master/iostat.c
* Read stats from /proc/diskstats.
void read_diskstats_stat(int curr)
...
/* major minor name rio rmerge rsect ruse wio wmerge wsect wuse running use aveq */
i = sscanf(line, "%u %u %s %lu %lu %lu %lu %lu %lu %lu %u %u %u %u",
&major, &minor, dev_name,
&rd_ios, &rd_merges_or_rd_sec, &rd_sec_or_wr_ios, &rd_ticks_or_wr_sec,
&wr_ios, &wr_merges, &wr_sec, &wr_ticks, &ios_pgr, &tot_ticks, &rq_ticks);
if (i == 14) {
....
sdev.rd_sectors = rd_sec_or_wr_ios;
....
sdev.wr_sectors = wr_sec;
....
* #fctr Conversion factor.
...
if (DISPLAY_KILOBYTES(flags)) {
printf(" kB_read/s kB_wrtn/s kB_read kB_wrtn\n");
*fctr = 2;
}
...
/* rrq/s wrq/s r/s w/s rsec wsec rqsz qusz await r_await w_await svctm %util */
... 4 columns skipped
cprintf_f(4, 8, 2,
S_VALUE(ioj->rd_sectors, ioi->rd_sectors, itv) / fctr,
S_VALUE(ioj->wr_sectors, ioi->wr_sectors, itv) / fctr,
So, read sector count and divide by two to get kilobyte/s (seems like 1 sector read is 0.5 kb read; 2 sector read is 1 kb read and so on). We can conclude that the sector is always 512 bytes. Same is stated in the doc, isn't it?:
internet search for "/proc/diskstats" ->
https://www.kernel.org/doc/Documentation/ABI/testing/procfs-diskstats ->
https://www.kernel.org/doc/Documentation/iostats.txt "I/O statistics fields" by ricklind from usa's ibm
Field 3 -- # of sectors read
This is the total number of sectors read successfully.
Field 7 -- # of sectors written
This is the total number of sectors written successfully.
No info about sector size here (why?). Is the source code being the best documentation (it may be)? The writer of /proc/diskstats is in kernel sources in file block/genhd.c, function diskstats_show:
http://lxr.free-electrons.com/source/block/genhd.c?v=4.4#L1149
1170 seq_printf(seqf, "%4d %7d %s %lu %lu %lu "
1171 "%u %lu %lu %lu %u %u %u %u\n",
...
1176 part_stat_read(hd, sectors[READ]),
...
1180 part_stat_read(hd, sectors[WRITE]),
Structure sectors is defined in http://lxr.free-electrons.com/source/include/linux/genhd.h?v=4.4#L82
82 struct disk_stats {
83 unsigned long sectors[2]; /* READs and WRITEs */
It is read with part_stat_read and written with __part_stat_add
http://lxr.free-electrons.com/source/include/linux/genhd.h?v=4.4#L307
Adding to the sectors counter ... is... at http://lxr.free-electrons.com/source/block/blk-core.c?v=4.4#L2264
2264 void blk_account_io_completion(struct request *req, unsigned int bytes)
2265 {
2266 if (blk_do_io_stat(req)) {
2267 const int rw = rq_data_dir(req);
2268 struct hd_struct *part;
2269 int cpu;
2270
2271 cpu = part_stat_lock();
2272 part = req->part;
2273 part_stat_add(cpu, part, sectors[rw], bytes >> 9);
2274 part_stat_unlock();
2275 }
2276 }
It uses hard-coded "bytes >> 9" to compute sector size from request size in bytes (why round down??) or for human, not no-floating-point compiler, it is the same as bytes / 512.
There is also blk_rq_sectors function (unused here...) to get sector count from request, which does the same >>9 from bytes to sectors
http://lxr.free-electrons.com/source/include/linux/blkdev.h?v=4.4#L853
841 static inline unsigned int blk_rq_bytes(const struct request *rq)
842 {
843 return rq->__data_len;
844 }
853 static inline unsigned int blk_rq_sectors(const struct request *rq)
854 {
855 return blk_rq_bytes(rq) >> 9;
856 }
Authors of FS/VFS subsystem in Linux says in reply to https://lkml.org/lkml/2015/8/17/234 "Why is SECTOR_SIZE = 512 inside kernel ?" (2015):
#define SECTOR_SHIFT 9
Message https://lkml.org/lkml/2015/8/17/269 by Theodore Ts'o:
It's cast in stone. There are too many places all over the kernel,
especially in a huge number of file systems, which assume that the
sector size is 512 bytes. So above the block layer, the sector size
is always going to be 512.
This is actually better for user space programs using
/proc/diskstats, since they don't need to know whether a particular
underlying hardware is using 512, 4k, (or if the HDD manufacturers
fantasies become true 32k or 64k) sector sizes.
For similar reason, st_blocks in struct size is always in units of 512
bytes. We don't want to force userspace to have to figure out whether
the underlying file system is using 1k, 2k, or 4k. For that reason
the units of st_blocks is always going to be 512 bytes, and this is
hard-coded in the POSIX standard.
For about 3 of my Amazon EC2 instances I noticed that each contains two 414GB partitions / devices.
cat /proc/partitions
major minor #blocks name
202 65 6291456 xvde1
202 144 440366080 xvdj
202 160 440366080 xvdk
df -h
Filesystem Size Used Avail Use% Mounted on
/dev/xvde1 5.7G 5.0G 605M 90% /
none 3.7G 0 3.7G 0% /dev/shm
/dev/xvdj 414G 276G 117G 71% /ebg
/dev/xvdk 414G 14G 380G 4% /eby
fdisk -l
Disk /dev/xvde1: 7516 MB, 7516192768 bytes
255 heads, 63 sectors/track, 913 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000000
_
Disk /dev/xvdj: 450.9 GB, 450934865920 bytes
255 heads, 63 sectors/track, 54823 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000000
_
Disk /dev/xvdk: 450.9 GB, 450934865920 bytes
255 heads, 63 sectors/track, 54823 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000000
My Question is that I dont know where these partitions came from and I need to know how I can recreate them in other instances. I have not been able to create an instance with these partitions present.
Also since these partitions are not shown in the volumes section of my EC2 Dashboard I dont know what they are and how much I am being charged for it.
I will appreaciate any help I can get. Thanks in Advance.
They appear to be instance store volumes. These are included in the price of the instance, but need to be explicitly enabled by the AMI or by you at launch.
While you can use instance store volumes to store data, they will get deleted if the instance is stopped or has failed.