Error ID: BLKCACHE_IOERR
Re: Error ID: BLKCACHE_IOERR
I got this error on VirtualBox 5.1.2 r108956 running on windows 10. I have more than enough disk space. I did try checking the cache I/O host option, but it didn't help. I then realized I'd set the disk type as qcow (Was planning on moving this VM to my kvm server). Changed it to a static vdi file, and no issues.
-
mpack
- Site Moderator
- Posts: 39134
- Joined: 4. Sep 2008, 17:09
- Primary OS: MS Windows 10
- VBox Version: PUEL
- Guest OSses: Mostly XP
Re: Error ID: BLKCACHE_IOERR
IO error means IO error, it isn't restricted to reporting lack of host disk space. I suggest that you run chkdsk on the host drive.
Re: Error ID: BLKCACHE_IOERR
I am getting this error as well.
This is a host NTFS problem, the reported error (655) has to do with fragmentation of a single file on the underlying file system, see links.
Short story: dynamic VDI files can end up very fragmented, which can cause this problem.
Short answer: Defrag the or use static VDI files. [For SSDs set defrag schedule to once a month to reduce sector wear]
Short request: Allow the user to set a minimum allocation size for dynamic VDI files.
It appears that when a program puts attributes on a file, and the file gets too fragmented, NTFS runs out of room for attributes on that file.
[Don't ask me for technical details of what the attributes are, I don't know them]
Copying a file will generally reduce its fragmentation, so this problem goes away until enough new fragments are created.
Host IO caching also postpones the problem, probably by aggregating what would be many small writes/fragments into fewer large writes/fragments.
It seems that VDI files get attributes attached to its fragments, which is too damn bad.
If the VDI files are static, no big deal, you either have the property space available for the fragments when the VDI is created, or it isn't created.
If they are dynamic, and it grows in lots little bits and pieces and if it is never defragged it will cause this problem.
If you are running on an HDD and routinely defrag you will probably never see this problem.
If like me, you are running your VM off an SSD, and don't defrag it*, this is going to show up if your VDI grows in a bunch of small steps.
*Because "defrag is bad for SSDs" due to wear leveling, and
"Defrag isn't needed on SSDs" because fragmentation doesn't cause the mechanical latency it does on HDDs.
My VDI I am having problems with is on an SSD and has grown to 72GB.
The largest free fragment on the SSD is 130MB. When I try to copy it to another SSD it fails.
I have been running a defrag on it for almost 2 hours and it is at "Pass 1: 0% defragmented"
supporting links (fill in the slashes and dots, I'm too new to post URLs)
dba . stackexchange . com questions\74209\the-operating-system-returned-error-665the-requested-operation-could-not-be-com
support . microsoft . com\en-us\help\2002606\os-errors-1450-and-665-are-reported-for-database-data-files
blogs . msdn . microsoft . com\psssql\2015\06\10\operating-system-error-665-file-system-limitation-not-just-for-dbcc-anymore\
This is a host NTFS problem, the reported error (655) has to do with fragmentation of a single file on the underlying file system, see links.
Short story: dynamic VDI files can end up very fragmented, which can cause this problem.
Short answer: Defrag the or use static VDI files. [For SSDs set defrag schedule to once a month to reduce sector wear]
Short request: Allow the user to set a minimum allocation size for dynamic VDI files.
It appears that when a program puts attributes on a file, and the file gets too fragmented, NTFS runs out of room for attributes on that file.
[Don't ask me for technical details of what the attributes are, I don't know them]
Copying a file will generally reduce its fragmentation, so this problem goes away until enough new fragments are created.
Host IO caching also postpones the problem, probably by aggregating what would be many small writes/fragments into fewer large writes/fragments.
It seems that VDI files get attributes attached to its fragments, which is too damn bad.
If the VDI files are static, no big deal, you either have the property space available for the fragments when the VDI is created, or it isn't created.
If they are dynamic, and it grows in lots little bits and pieces and if it is never defragged it will cause this problem.
If you are running on an HDD and routinely defrag you will probably never see this problem.
If like me, you are running your VM off an SSD, and don't defrag it*, this is going to show up if your VDI grows in a bunch of small steps.
*Because "defrag is bad for SSDs" due to wear leveling, and
"Defrag isn't needed on SSDs" because fragmentation doesn't cause the mechanical latency it does on HDDs.
My VDI I am having problems with is on an SSD and has grown to 72GB.
The largest free fragment on the SSD is 130MB. When I try to copy it to another SSD it fails.
I have been running a defrag on it for almost 2 hours and it is at "Pass 1: 0% defragmented"
supporting links (fill in the slashes and dots, I'm too new to post URLs)
dba . stackexchange . com questions\74209\the-operating-system-returned-error-665the-requested-operation-could-not-be-com
support . microsoft . com\en-us\help\2002606\os-errors-1450-and-665-are-reported-for-database-data-files
blogs . msdn . microsoft . com\psssql\2015\06\10\operating-system-error-665-file-system-limitation-not-just-for-dbcc-anymore\