Hi Gordon,
it looks like that recently added 16-bit charsets added few bugs
into VFAT code. I was really surprised when I found that for
VLAKC.TTR short name is VLAKCTTR...
I'm not VFAT guru, so please can you review this patch and
eventually fix it or send to Linus?
Hi,
While trying to get affs working again, I noticed that the current
cont_prepare_write is hardly working, if you write to a file in steps of
1024, the bytes pointer is never updated resulting in an endless loop.
Below is a fixed version, that also removes the bogus tricks to the
bytes ptr. I
On Mon, 24 Jul 2000, Roman Zippel wrote:
Hi,
While trying to get affs working again, I noticed that the current
cont_prepare_write is hardly working, if you write to a file in steps of
1024, the bytes pointer is never updated resulting in an endless loop.
Testcase, please? It certainly
Hi,
While trying to get affs working again, I noticed that the current
cont_prepare_write is hardly working, if you write to a file in steps of
1024, the bytes pointer is never updated resulting in an endless loop.
Testcase, please? It certainly seems to be working on FAT and HPFS -
Jeremy writes:
Hmm...no, I'm not booting from a ramdisk. The only ramdisk involved is to
initialize my scsi adapter and I've already successfully install the
journal on my scsi drive's partition.
The problem is that you probably have a journal option in your lilo.conf
file, which is getting
On Mon, 24 Jul 2000, Roman Zippel wrote:
Hi,
While trying to get affs working again, I noticed that the current
cont_prepare_write is hardly working, if you write to a file in steps of
1024, the bytes pointer is never updated resulting in an endless loop.
Testcase, please? It
On Mon, 24 Jul 2000, Alexander Viro wrote:
Not needed. That race is taken care of - readpage() never does access past
i_size and has the page locked, while vmtruncate() starts with setting
i_size (on shrinking truncate(), that is), then goes through all pages in
affected area and grabs the
Hi,
Because actual _allocation_ unit may have nothing to blocksize and be
invisible to VFS. Check fatfs - it uses the thing to trigger allocation,
but actual zero-out goes on per-sector basis.
I tried vfat on a MO drive with 1KByte sectors - it doesn't work. I also
don't know how you want to
Hi!
I've been looking at the possibility of cleanly implementing virtual
files (podfuk/avfs style) with the multiple mount thing in 2.4
kernels. Here is how it would work:
1) There needs to be a global lookup hook in VFS. If a real lookup
fails, the global lookup is invoked. The cached
On Mon, 24 Jul 2000, Pavel Machek wrote:
Hi!
I've been looking at the possibility of cleanly implementing virtual
files (podfuk/avfs style) with the multiple mount thing in 2.4
kernels. Here is how it would work:
1) There needs to be a global lookup hook in VFS. If a real lookup
On Mon, Jul 24, 2000 at 12:04:39PM -0400, Benjamin C.R. LaHaise wrote:
On Mon, 24 Jul 2000, Alexander Viro wrote:
Not needed. That race is taken care of - readpage() never does access past
i_size and has the page locked, while vmtruncate() starts with setting
i_size (on shrinking
I build some customized kernel rpm's for our inhouse distro and I've
incorporated the profiling patches to use the sard utility. I'm just
curious if there is any downside to using this patch for any reason and if
there are any concerns for stability using this patch?
Thanks
-jeremy
--
On Mon, Jul 24, 2000 at 02:24:42PM -0400, Jan Harkes wrote:
On Mon, Jul 24, 2000 at 12:04:39PM -0400, Benjamin C.R. LaHaise wrote:
On Mon, 24 Jul 2000, Alexander Viro wrote:
Not needed. That race is taken care of - readpage() never does access past
i_size and has the page locked,
13 matches
Mail list logo
