39 lines
1.6 KiB
Plaintext
39 lines
1.6 KiB
Plaintext
NTFS - list of things to do in no particular order:
|
|
|
|
- handle Unicode chars more inteligently - currently only iso-8859-1
|
|
chars are supported, it should be possible to get the filename
|
|
converted into koi-8, iso-8859-2 & utf-8 at least - there is
|
|
some Unicode support present under FreeBSD, would be worth considering
|
|
for adoption (it's needed to properly support Juliet CDs anyway)
|
|
FreeBSD info: http://triaez.kaisei.org/~mzaki/joliet/
|
|
* not very hard
|
|
|
|
- better support for writing; tricky is crash recovery
|
|
|
|
- cleanup the mess with several *readattr*() functions if possible
|
|
|
|
- avoid allocation temporary buffer to hold result of read()/data
|
|
to be written in ntfs_read() & ntfs_write(): it's very easy
|
|
to panic the kernel that way, with simple
|
|
read(open(...), NULL, some_very_big_number);
|
|
The data should be transfered directly to the user buffer
|
|
(from Chuq)
|
|
* finishing testing, even gained about 3-5% performance improvement
|
|
for simple cat file >/dev/null test
|
|
|
|
- ntfs_ntvattrget() identify if it's worth the efford to use some hashing
|
|
for the list of ntnodes, so that it's not all scanned each time; it would
|
|
be fine to migrate the found ntnode towards the start of the list too;
|
|
the list search code is duplicated on two places, eliminate the duplicity
|
|
somehow
|
|
|
|
- convert to code to do caching in buffer cache indexed by
|
|
file-vnode/file-offset so that NTFS would take advantage of UBC;
|
|
it should also improve performance somewhat, because if it's necessary
|
|
to find some offset in a file, it's possible to check if the data
|
|
are available in the cache before doing the bmap operation first
|
|
(from Chuq)
|
|
|
|
- working VOP_BALLOC()
|
|
(from Chuq)
|