Opened 11 years ago
Last modified 5 years ago
#10399 assigned bug
KDL Copying on ext4: sparse write attempt: vnode 0xe0056b60
Reported by: | humdinger | Owned by: | axeld |
---|---|---|---|
Priority: | normal | Milestone: | R1 |
Component: | File Systems/ext2 | Version: | R1/Development |
Keywords: | Cc: | ||
Blocked By: | Blocking: | ||
Platform: | All |
Description
This is hrev46645.
When I try copying 2 small files and 2 big (600mb) files onto a ext4 formatted USB drive, the small files are copied, but while about halfway into the first big file, I'm thrown in KDL: "PANIC: sparse write attempt: vnode 0xe0056b60" (see attached photo.)
I can continue, but am immediately back in KDL.
Attachments (1)
Change History (6)
by , 11 years ago
Attachment: | ext4_crash.jpg added |
---|
comment:1 by , 11 years ago
The panic exists since hrev28648. Does the big files already exist on the target drive?
Otherwise a bad file map returned by the fs addon could eventually explain the panic.
comment:2 by , 8 years ago
Owner: | changed from | to
---|---|
Status: | new → assigned |
axeld added the panic. Axel, any idea why happening?
comment:3 by , 8 years ago
AFAIR, it works like this:
- On read, the file system marks extents of the file with the special on disk location -1 as being non existent. The file cache will then fill those with zeros.
- On write, the file system must make sure that all portions of the file being written to are non sparse, first. Otherwise, the file cache simply doesn't know where to put the data. That's what this panic means.
So ext2 must check if the write will "unsparse" a sparse file first, allocate space for it, update the file cache mappings, and only then actually perform the write by handing off the data to the file cache.
comment:4 by , 8 years ago
IOW you have to allocate the stream before writing to it just like if you added data at its end.
KDL when writing to ext2 USB harddisk