注意：这篇里讲解的代码都是来自liblightnvm.git(lightnvm的用户态库，注意是最新的库，而不是先前那个由Matias Bjørling自己写的旧liblightnvm库)
Some Kinds of Address
1.PPA（位域操作符定义的struct）[generic address]
struct nvm_addr {
union {
/**
* Address packing and geometric accessors
*/
struct {
uint64_t blk : NVM_BLK_BITS; ///< Block address
uint64_t pg : NVM_PG_BITS; ///< Page address
uint64_t sec : NVM_SEC_BITS; ///< Sector address
uint64_t pl : NVM_PL_BITS; ///< Plane address
uint64_t lun : NVM_LUN_BITS; ///< LUN address
uint64_t ch : NVM_CH_BITS; ///< Channel address
uint64_t rsvd : 1; ///< Reserved
} g;
struct {
uint64_t line : 63; ///< Address line
uint64_t is_cached : 1; ///< Cache hint?
} c;
uint64_t ppa; ///< Address as ppa
};
};
PPA is NOT an address accepted by ssd controller, but an address for each part through a machine-can-tell address.(or I call it a human-readable-each-part-address-----generic address)
Let me explain by a simple example below:
a 16b machine-can-tell address 1101 1011 0000 0011
---- ---- ---- ----
break apart P1 P2 P3 P4
struct example_addr{ | | | |
union{ | | | |
struct { | | | | (in decimal)
uint16_t p1 : 16;----| | | | 13
uint16_t p2 : 16;-----------| | | 11
uint16_t p3 : 16;----------------| | 0
uint16_t p4 : 16;---------------------| 3
} g;
//other field
uint16_t ppa;
};
};
2.同时,又有一个机器格式的地址 （device-address，which follows the fmt format）
struct nvm_dev {
char name[NVM_DEV_NAME_LEN]; ///< Device name e.g. "nvme0n1"
char path[NVM_DEV_PATH_LEN]; ///< Device path e.g. "/dev/nvme0n1"
struct nvm_addr_fmt fmt; ///< Device address format
struct nvm_addr_fmt_mask mask; ///< Device address format mask
struct nvm_geo geo; ///< Device geometry
uint64_t ssw; ///< Bit-width for LBA fmt conversion
int pmode; ///< Default plane-mode I/O
int fd; ///< Device fd / IOCTL handle
int erase_naddrs_max; ///< Maximum # of address for erase
int read_naddrs_max; ///< Maximum # of address for read
int write_naddrs_max; ///< Maximum # of address for write
int bbts_cached; ///< Whether to cache bbts
size_t nbbts; ///< Number of entries in cache
struct nvm_bbt **bbts; ///< Cache of bad-block-tables
};
- 为什么会有一个ppa，又有一个fmt和mask？
- 个人推测：
ppa这种地址有一定的间隙，比如最大可以表示一个uint64_t的地址空间，但实际如flash本身size没这么大，有某些域会永远是零，特定的OCSSD，其地址格式（dev->fmt） will be different.
My Fucking Input Software broke down:(... So I'm going to talk in Eng. - so convertion between a ppa and a device-format addr.:
generic --> dev-format
inline uint64_t nvm_addr_gen2dev(struct nvm_dev *dev, struct nvm_addr addr)
{
uint64_t d_addr = 0;
d_addr |= ((uint64_t)addr.g.ch) << dev->fmt.n.ch_ofz;
d_addr |= ((uint64_t)addr.g.lun) << dev->fmt.n.lun_ofz;
d_addr |= ((uint64_t)addr.g.pl) << dev->fmt.n.pl_ofz;
d_addr |= ((uint64_t)addr.g.blk) << dev->fmt.n.blk_ofz;
d_addr |= ((uint64_t)addr.g.pg) << dev->fmt.n.pg_ofz;
d_addr |= ((uint64_t)addr.g.sec) << dev->fmt.n.sec_ofz;
return d_addr;
}
generic <-- dev-format
inline struct nvm_addr nvm_addr_dev2gen(struct nvm_dev *dev, uint64_t addr)
{
struct nvm_addr gen;
gen.ppa = 0;
gen.g.ch = (addr & dev->mask.n.ch) >> dev->fmt.n.ch_ofz;
gen.g.lun |= (addr & dev->mask.n.lun) >> dev->fmt.n.lun_ofz;
gen.g.pl|= (addr & dev->mask.n.pl) >> dev->fmt.n.pl_ofz;
gen.g.blk |= (addr & dev->mask.n.blk) >> dev->fmt.n.blk_ofz;
gen.g.pg |= (addr & dev->mask.n.pg) >> dev->fmt.n.pg_ofz;
gen.g.sec |= (addr & dev->mask.n.sec) >> dev->fmt.n.sec_ofz;
return gen;
}
3.另外就是lba和offset了，这两个比较好理解吧.
offset-format address: 偏移量是以字节（byte）为单位的.上面说的gen-fmt和dev-fmt可以说最终是指明了哪一个sector，那么从sector到offset的关系很容易就可以猜想，是要乘以每sector的字节数，这里的geo指出是4096个字节，因此就是乘以4096也就是左移12位.
so:
gen-fmt --> offset
uint64_t nvm_addr_gen2off(struct nvm_dev *dev, struct nvm_addr addr)
{
return nvm_addr_gen2dev(dev, addr) << dev->ssw;
}
至于这里为啥要先转成dev-fmt，这里我也有些不理解。
先说下不理解的根源是与我们的直觉不符，我们直觉上应该：
从意义上，offset指定的是某个sector的某个byte。地址应该是先转成第x个sector，并把这个x乘以4096才对，刚才的x并不等于dev-fmt的addr。
我给此的解释是这样的：
从下面的fmt-mask可以看出pg与blk的位置对换了，但这就是dev-fmt你无法选择。事实上dev-fmt想把lun放在最右边你也没办法阿～科科，我可以说机器的地址线的这几列老子就是解释成lun你想怎样？
但总和上不管把dev的地址的某几位解释成什么，offset的总量是固定的，只是对于某个ofs，特定的解释方式可能得到不同的某个sector中的某个byte.
但只要解释成ofs和从ofs解释回dev的方式固定，得到的特定byte是自恰的.
fmt-mask {
ch(0000000000000000000000000000000000000000000000000000000000000000),
lun(0000000000000000000000000000000000000000011000000000000000000000),
pl(0000000000000000000000000000000000000000000100000000000000000000),
blk(0000000000000000000000000000000000000000000000000000111111111111),
pg(0000000000000000000000000000000000000000000011111111000000000000),
sec(0000000000000000000000000000000000000000000000000000000000000000)
}
lba-format address：这个就同理，刚才的单位是byte，这里因为一些标准的缘故，lba貌似是指最初的rotating disk的sector的单位（512字节），因此从offset转到lba就是再<B>除以</B>512，也就是左移9位.
gen-fmt --> lba(#define NVM_UNIVERSAL_SECT_SH 9 : see nvm.h)
uint64_t nvm_addr_gen2lba(struct nvm_dev *dev, struct nvm_addr addr)
{
return nvm_addr_gen2off(dev, addr) >> NVM_UNIVERSAL_SECT_SH;
}
最后的最后：一些使用nvm_addr的quick example.
- Iteration over all sectors : see
test_addr_conv.c
supposegeohere is like: (as what we've got in last blog)
geo {
nchannels(1), nluns(4), nplanes(2),
nblocks(2044), npages(256), nsectors(1),
page_nbytes(4096), sector_nbytes(4096), meta_nbytes(16),
tbytes(17146314752b:16352Mb),
vpg_nbytes(8192b:8Kb),
vblk_nbytes(2097152b:2Mb)
}
now,iterate all sectors we have:(sector is THE MINIMAL granularity one can access into a disk)
size_t tsecs = geo->nchannels * geo->nluns * geo->nplanes * geo->nblocks * geo->npages * geo->nsectors;
for (int sec = 0; sec < tsecs; ++sec) {
struct nvm_addr expected;
expected.ppa = 0;
expected.g.sec = sec % geo->nsectors;//this is how we get a PPA(by hand-calculating)
expected.g.pg = (sec / geo->nsectors ) % geo->npages;//:=
expected.g.blk = ((sec / geo->nsectors) / geo->npages ) % geo->nblocks;
expected.g.pl = (((sec / geo->nsectors) / geo->npages ) / geo->nblocks) % geo->nplanes;
expected.g.lun = ((((sec / geo->nsectors) / geo->npages ) / geo->nblocks) / geo->nplanes) % geo->nluns;
expected.g.ch = (((((sec / geo->nsectors) / geo->npages ) / geo->nblocks) / geo->nplanes) / geo->nluns) % geo->nchannels;
//do something with that sector_number.
}
- nvm_addr赋值.
#include <liblightnvm.h>
struct nvm_addr a,b;
b.ppa = 0;//所有域赋为0
a.ppa = b.ppa;//把b表示的地址赋给a
