At 00:59 26/05/2001, Jeff Garzik wrote:
>Anton Altaparmakov wrote:
> > NTFS 1.1.15 - ChangeLog
> > ===
> > - Support for more than 128kiB sized runlists (using vmalloc_32() instead
> > of kmalloc()).
>
>If you are running into kmalloc size limit, please consider some
>alternat
> I would love to move inode metadata to the page cache. That would simplify
> so much in the NTFS driver and would result in an incredible speed boost
> due to getting rid of all the silly copying of data back and forth inside
> the driver as we could just pass pointers around instead (to lock
At 12:23 27/05/2001, Martin von Loewis wrote:
> > I would love to move inode metadata to the page cache. That would simplify
> > so much in the NTFS driver and would result in an incredible speed boost
> > due to getting rid of all the silly copying of data back and forth inside
> > the driver as
> Yes and no. They will be uncompressed but not when opening the inode. It
> will be "uncompress required extent's run list on demand".
Are you sure this can work? Initially, I thought I could use the
attribute list to only uncompress the extend that has the VCN I'm
interested in.
That would no
At 13:53 27/05/2001, Martin von Loewis wrote:
> > Yes and no. They will be uncompressed but not when opening the inode. It
> > will be "uncompress required extent's run list on demand".
>
>Are you sure this can work?
No.
>Initially, I thought I could use the attribute list to only uncompress the
Martin von Loewis wrote:
>That would not work: NT would split individual runs across extends
>(i.e. split them in the middle). Did I misunderstand, or do you have a
>solution for that as well.
>
Are you sure that it's true? My NTFS resizer interprets parts of runlist
stored in different FILE rec
> >That would not work: NT would split individual runs across extends
> >(i.e. split them in the middle). Did I misunderstand, or do you have a
> >solution for that as well.
> >
> Are you sure that it's true? My NTFS resizer interprets parts of runlist
> stored in different FILE records independe
At 12:10 28/05/2001, Martin von Loewis wrote:
> > >That would not work: NT would split individual runs across extends
> > >(i.e. split them in the middle). Did I misunderstand, or do you have a
> > >solution for that as well.
> > >
> > Are you sure that it's true? My NTFS resizer interprets parts
Anton Altaparmakov wrote:
> Does anyone know what NTFS version the NT 3.1 / 3.51 volumes had? If I
> know I can make sure we don't mount such beasts considering we know
> the driver would fail on them... - I am aware of only one person stil
> using NT 3.51 and he doesn't believe in the NTFS
At 14:08 28/05/2001, Yuri Per wrote:
>Anton Altaparmakov wrote:
>
>>Does anyone know what NTFS version the NT 3.1 / 3.51 volumes had? If I
>>know I can make sure we don't mount such beasts considering we know the
>>driver would fail on them... - I am aware of only one person stil using
>>NT 3
On Mon, May 28, 2001 at 03:49:28PM +0100, Anton Altaparmakov wrote:
> At 14:08 28/05/2001, Yuri Per wrote:
> >Anton Altaparmakov wrote:
> >
> >>Does anyone know what NTFS version the NT 3.1 / 3.51 volumes had? If I
> >>know I can make sure we don't mount such beasts considering we know the
> >>
> > Anyone know about 3.1?
> >
>
> It's an HPFS variant.
No. NT was using NTFS right from the start.
Regards,
Martin
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-
On Tue, May 29, 2001 at 10:18:41AM +0200, Martin von Loewis wrote:
> > > Anyone know about 3.1?
> > >
> >
> > It's an HPFS variant.
>
> No. NT was using NTFS right from the start.
>
> Regards,
> Martin
No. They were not. Their first cuts of NT used an HPFS variant until
NTFS could be compl
13 matches
Mail list logo
