Additional ext4-backed mount point for high-throughput I/O caching (besides `/kaggle/working`)
Nobody has claimed this yet.
Assessment
- Difficulty
- 5/5
- Estimated time
- Over a week
- Newbie friendliness
- 25/100
- Issue type
- Feature
- Clarity
- Mostly clear
- Activity status
- Stale
- Tech stack
- docker, linux
- Domain
- infrastructure, operating-systems
Research direction
Start by reviewing the issue’s I/O benchmark and the existing container mount configuration; no implementation files or tests are named in the report. Define the additional physical-device-backed ext4 mount separately from /kaggle/working, then verify that it provides a larger, faster cache path without changing the existing mount behavior.
Written by the indexing model from the issue text.
Description
🚀 Feature
Provide an additional mount point backed by a physical device (ext4), separate from /kaggle/working, to use as a high-throughput I/O cache (e.g., /tmp).
Motivation
- The container root (
/) appears to be provided via an overlay filesystem; write/metadata performance on overlay can be slower or less predictable than on a host-backed volume such as/kaggle/working. - Some applications default to
/tmpfor I/O-intensive caches; on overlay this default can become an I/O bottleneck. /kaggle/workingis relatively fast and can be an alternatives to/tmp, but its capacity is limited to ~20 GB per session, which is sometimes insufficient to host checkpoint of LLMs (~100GB).- An additional fast endpoint for caching has the potential to better utilize the instance’s compute resources (e.g., T4, P100) that are often bottlenecked by disk I/O.
Additional context
I benchmarked sequential I/O and observed both writes and reads to be slower on /tmp (overlay) than on /kaggle/working (host-backed). Write throughput on /tmp is especially unstable; it sometimes gets ~5–10× lower in my tests.
- Dominant language
- Python
- Stars
- 2.7k
- Forks
- 1k
- Avg merge
- 5h 55m
- Merged PRs (30d)
- 1
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from Kaggle/docker-python
-
enhancement
Difficulty 2/5 1-3 hours Newbie friendliness 65/100
Kaggle/docker-python#1482 · 2 reactions ·
-
ذ Open
Difficulty 5/5 Over a week Newbie friendliness 1/100
Kaggle/docker-python#1555 ·
-
bug help wanted
Difficulty 4/5 3-5 days Newbie friendliness 42/100
Kaggle/docker-python#1546 · 4 comments · 2 reactions ·
-
Difficulty 4/5 3-5 days Newbie friendliness 25/100
Kaggle/docker-python#1515 ·
-
bug help wanted
Difficulty 4/5 3-5 days Newbie friendliness 35/100
Kaggle/docker-python#1504 ·
All issues in Kaggle/docker-python
Similar issues
-
Add: hunch Open
Difficulty 2/5 1-3 hours Newbie friendliness 74/100
AbdelStark/awesome-typesafe#104 ·
-
enhancement
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
DiamondLightSource/dodal#2211 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
openml/openml-python#1749 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
sipyourdrink-ltd/bernstein#6191 ·