thảo luận Hội Dev 35 đi phỏng vấn tìm việc.

odkjabqpmzvmz đã nói:

He cám ơn bác bổ sung. Em không làm low level nên thấy đoạn bác nói về low level rất khai sáng. Em đang theo hướng buffer write dùng queue như bác nói, nhưng chắc nên bổ sung thêm việc "batching" nữa: đại loại sẽ "gộp" các lệnh write vào để đỡ bị nhiều. Ví dụ lệnh +100, +200 thì gộp thành lệnh +300 cũng là một cách để đỡ nặng.

Về trade-off bác nói cũng đúng. Cả hệ thống lẫn phương pháp, mỗi thứ mình chọn sẽ có ưu, nhược điểm riêng, tùy trường hợp mà mình nên chọn cái phù hợp. Ví dụ nếu như yêu cầu dữ liệu load nhanh, nhưng không nặng phải mới nhất/up to date thì có thể chơi cache xong refresh. Cái việc nên trường hợp rồi chọn phù hợp thì cũng tự nhận em chưa đủ trình để đưa ra một cái thực sự bao quát, mà thường vào tình huống thực tế mới nói được :stick:

Nhấp để mở rộng...

thisismyfirstclone đã nói:

SSD vẫn dùng sequential writes vì random writes sẽ làm tăng tính bào mòn của transistors và giảm độ tin cậy của dữ liệu.

Nhấp để mở rộng...

thisismyfirstclone đã nói:

Các database hiện nay đều dùng cách này

Nhấp để mở rộng...

thisismyfirstclone đã nói:

https://www.usenix.org/legacy/event/usenix08/tech/full_papers/agrawal/agrawal.pdf

lol Lmao, assuming you understand what a Log-Structured File System is

In the worst case, where superseded pages are distributed evenly across all blocks, N − 1 cleaning writes must be issued for every new data write (where there are N pages per block). Of course, most workloads produce clusters of write activity, which in turn lead to multiple superseded pages per block when the data is overwritten. We introduce the term cleaning efficiency to quantify the ratio of superseded pages to total pages during block cleaning. Although there are many possible algorithms for choosing candidate blocks for recycling, it is always desirable to optimize cleaning efficiency. It’s worth noting that the use of striping to enhance parallel access for
sequential addresses works against the clustering of superseded pages.


It might be tempting to view block cleaning as similar to log-cleaning in a Log-Structured File System [28] and indeed there are similarities. However, apart from the obvious difference that we model a block store as opposed to a file system, a log-structured store that writes
and cleans in strict disk-order cannot choose candidate blocks so as to yield higher cleaning efficiency. And, as with LFS-like file systems, it’s altogether too easy to combine workloads that would cause all recoverable space to be situated far from the log’s cleaning pointer. For example, writing the same sets of blocks over and over would require a full cycle over the disk content in order for the cleaning pointer to reach the free space near the end of the log. And, unlike a log-structured file
system, the disk here is always “full”, corresponding to maximal cleaning pressure all the time.

Nhấp để mở rộng...

thisismyfirstclone đã nói:

oh a dog, I forgot, why should I reply a dog

Nhấp để mở rộng...

thisismyfirstclone đã nói:

Các database hiện nay đều dùng cách này

Nhấp để mở rộng...

thisismyfirstclone đã nói:

oh a dog, I forgot, why should I reply a dog

Nhấp để mở rộng...

thisismyfirstclone đã nói:

oh a dog, I forgot, why should I reply a dog

Nhấp để mở rộng...

small-lambda đã nói:

SSD đọc và ghi theo đơn vị gọi là page, kích cỡ tùy nsx, có vẻ tầm 4Kb đến 16KB

nếu dữ liệu nhỏ hơn đơn vị đó thì nó phải lôi nguyên cái page chứa phần dữ liệu đó lên khi đọc, hoặc khi viết thì nó phải viết đè lên thì nó phải viết đè lên cái page chứa phần dữ liệu đó chứ không chỉ đè lên phần dữ liệu nhỏ không thôi

mỗi khi sinh ra lệnh IO thì process phải gửi lệnh cho disk controller đẻ controller làm việc đọc viết, bản thân quá trình này sinh ra overhead về thời gian

trong trường hợp có nhiều lệnh write nhỏ hơn pagesize, nếu map 1-1 các lệnh write đó sang command cho disk controller, bỏ qua việc disk controller đó có thể có cơ chế buffering của riêng nó, thì phải trả giá overhead thời trên bằng tổng số lệnh write, đồng thời có thể có trường hợp phải write lên cùng một page nhiều lần

cho nên mới sinh ra chuyện gộp các lệnh write gốc, map nhiều lệnh write gốc vào 1 lệnh write cho controller, cái tiết kiệm ở đây phần nhiều hơn là thời gian chứ không phải là tuổi thọ SSD

khi buffer như vầy lệnh write sinh ra chưa chắc gì viết lên nhiều page liền kề, nên nếu có hàm ý là buffer writes thì lợi dụng được tính chất sequential writes nhanh hơn random writes thì cũng sai

có chăng thì thiết kế CTDL để nó lợi dụng việc sequential writes nhanh hơn, như cái LSM mà đứa nào đó vừa quote, chứ buffer writes nó không liên quan lắm

Nhấp để mở rộng...

thisismyfirstclone đã nói:

Tù từ t trả lời m đây

Vì khái niệm block và page trong ssd khác với khái niệm trong os và file system, nên ssd phải có một task là block mapping. Mục đích của nó là map từ logical block (abtraction mà file system sử dụng) sang physical block trên ssd.
Cách căn bản nhất là block-based mapping, nhưng cách này như m nói đấy, "small writes" (tức là sửa một lượng dữ liệu size nhỏ hơn một physical block), thì nó sẽ phải read toàn bộ block ấy vào memory và chỉnh sửa, sau đó mới ghi vào một block khác. Lúc này mapping trong memory sẽ trỏ logical block đến vị trí block mới. Còn block cũ sẽ bị garbage collection clear sau một khoảng thời gian. Do đó còn có các mapping approach khác là hybrid mapping, page mapping, vv.
SSD có 3 operations chính: read, program và clean và một đặc điểm là chỉ có thể clean theo block (không thể clean theo từng page). Thế nên như cái bài t gửi ấy, nó nói là "It’s worth noting that the use of striping to enhance parallel access for sequential addresses works against the clustering of superseded pages", nghĩa là việc phân bố data các page ra để tăng parallel access thì cái việc clean nó kém hiệu quả đi, do nó phải clear nhiều block, mỗi block lại rải rác vài page.
Chính vì cái write process này (program/clean) mà SSD nó còn có thêm khái niệm wear out (bào mòn). Cái bài mà t gửi ấy nó là một cái ví dụ cho khái niệm wear leveling.

Trong SSD còn có một khái niệm là disturbance (read/program disturbances) nghĩa là khi đọc hoặc ghi quá nhiều vào một page, thì có khả năng là các bit của các page lân cận bị flip. (vd 0 thành 1).

Còn cái này "khi buffer như vầy lệnh write sinh ra chưa chắc gì viết lên nhiều page liền kề, nên nếu có hàm ý là buffer writes thì lợi dụng được tính chất sequential writes nhanh hơn random writes thì cũng sai"
thì đúng, thế nên nó mới có một heuristics trong file system design là locality, tức là các file gần nhau (vd trong cùng thư mục), có khả năng được access liên tục hơn là các file xa nhau.

Thế nên kể cả ssd thì vẫn ưu tiên cho việc sequential writes. Vì random writes thì kể cả HDD vẫn làm được nhưng nó làm giảm hiệu năng. Ngoài ra random writes còn tăng khả năng fracmentation (dữ liệu của một file spread trên nhiều block).

Thế đã ok chưa lmao?

Nhấp để mở rộng...

thisismyfirstclone đã nói:

Thế nên kể cả ssd thì vẫn ưu tiên cho việc sequential writes. Vì random writes thì kể cả HDD vẫn làm được nhưng nó làm giảm hiệu năng. Ngoài ra random writes còn tăng khả năng fragmentation (dữ liệu của một file spread trên nhiều block).

Nhấp để mở rộng...

thisismyfirstclone đã nói:

Vì khái niệm block và page trong ssd khác với khái niệm trong os và file system, nên ssd phải có một task là block mapping. Mục đích của nó là map từ logical block (abtraction mà file system sử dụng) sang physical block trên ssd.

Nhấp để mở rộng...

small-lambda đã nói:

có ai nói là xài SSD thì không nên thiết kế CTDL để tận dụng tốc độ sequential writes đâu, vấn đề là nó không liên quan mấy chuyện buffer writes, buffer writes nó sinh ra từ mấy nguyên do khác


ok, nhưng như vầy thì liên quan gì tới chuyện dùng write buffer?

Nhấp để mở rộng...

thisismyfirstclone đã nói:

ok thế m giải thích cái buffer writes của m đi

Nhấp để mở rộng...

small-lambda đã nói:

ý là không thấy lắm chuyện buffer writes là đi tận dụng sequential writes ntn, hay là buffer writes sinh ra một phần vì seq wr

Nhấp để mở rộng...

thisismyfirstclone đã nói:

Có write buffering thì mới có sequential writes, không có write bufffering, có lệnh write là write luôn thì sequential con mẹ gì?

Nhấp để mở rộng...