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
> > 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
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
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 completed. The guy
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
>
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
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
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
> >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
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 independently and
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 of runlist
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.51 and
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
driver would
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
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
> 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
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
> 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
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 locked
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 we
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 not
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
extend
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
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
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
alternative method of allocation.
Can you map it into the
Announcing a new NTFS patch (1.1.15). It is generated against kernel
2.4.4-ac16 but also applies cleanly to -ac17. Quite probably it will apply
fine to any 2.4.4 kernel (at least 2.4.4-pre5 I think).
How to get the patch
- Wait for one of the next -ac series kernel
Announcing a new NTFS patch (1.1.15). It is generated against kernel
2.4.4-ac16 but also applies cleanly to -ac17. Quite probably it will apply
fine to any 2.4.4 kernel (at least 2.4.4-pre5 I think).
How to get the patch
- Wait for one of the next -ac series kernel
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
alternative method of allocation.
Can you map it into the page
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
alternative method
29 matches
Mail list logo
