|
Lewis Donzis
07/20/2009 10:52 PM
post34142
|
Do any of the QNX filesystem drivers support individual files larger than 4GB? My recollection is that the qnx4
directory entry has a 32-bit file size, so it's a significant limitation. I had hoped that, as a new design, qnx6
filesystem might have included a 64-bit file size, but it also appears to have the same limitation. I considered trying
ext2, but wasn't sure that's a highly reliable filesystem compared to qnx4?
Any plans 64-bit directory entries in any of the mainstream filesystem drivers in the future?
Thanks,
lew
|
|
|
|
|
|
John Garvey
07/21/2009 12:09 AM
post34146
|
Lewis Donzis wrote:
> Do any of the QNX filesystem drivers support individual files larger than 4GB?
For r/w, fs-qnx6 does. For r/o, fs-mac, fs-udf, fs-nt all do.
fs-dos supports r/w files up to 4GB (unsigned 32-bit). fs-qnx4 and
fs-ext2 are r/w to 2GB max (signed 32-bit).
> I had hoped that, as a new design, qnx6 filesystem might have included a 64-bit file size, but it also appears to
have the same limitation.
It is definitely 64-bit; where did you get the impression it was not
(so we can correct this if it was any of our docs)?
> Any plans 64-bit directory entries in any of the mainstream filesystem drivers in the future?
Yes - fs-qnx6 is the default HDD filesystem for QNX 6.4 and is 64-bit.
|
|
|
|
|
|
Lewis Donzis
07/21/2009 12:44 AM
post34149
|
Thanks for the quick reply.
That's great to hear that qnx6 is 64-bit, sorry for the misunderstanding. Now I have to try to figure out where I read
it. I vaguely recall reading through the announcement, not finding any claim that this is one of the new advantages.
And I also vaguely remember finding something "disappointing" that led me to believe that it was still 32-bit sizes.
No matter, I'm happy to hear that it relieves the issue for us.
I also recall getting the impression that qnx6 fs is designed to be super-safe but may not necessarily perform as well
as qnx4... is that also a misunderstanding?
Thanks,
lew
|
|
|
|
|
|
John Garvey
07/21/2009 1:13 AM
post34150
|
Lewis Donzis wrote:
> That's great to hear that qnx6 is 64-bit, sorry for the misunderstanding. Now I have to try to figure out where I
read it. I vaguely recall reading through the announcement, not finding any claim that this is one of the new
advantages. And I also vaguely remember finding something "disappointing" that led me to believe that it was still 32-
bit sizes.
The (internal devb) disk API remains a 32-bit blkno, which limits to
2TB HDD, and there was no attempt to consider potential expansion, as
that's not really my (our?) target market. Maybe something like that?
> I also recall getting the impression that qnx6 fs is designed to be super-safe but may not necessarily perform as well
as qnx4... is that also a misunderstanding?
There is no free lunch. The strong powersafe guarantees do have a cost
(COW relocation, flushing of the on-disk cache, etc), but this is
balanced to some degree by not needing to mitigate crash recovery via
ordered metadata synchronous writes. Some things will be slower, some
faster. I'd say on the whole for 6.4.0 fs-qnx6 is slower than fs-qnx4,
this is improved somewhat for 6.4.1, and 6.4.2 it is looking like at
least equal (if not better, as things got tweaked).
But it is really going to depend on the usage pattern, so hard to
generalise; although how expensive is a potential chkfsys?!
|
|
|
|
|
|
Lewis Donzis
07/21/2009 1:45 AM
post34152
|
Perhaps that was it, not sure. It seems like such a major new feature, though, you'd think it would be touted more.
2TB is quite enough for us. (famous last words!)
Actually, 64-bit memory would be nice, too (on x86) -- I presume that's on the OS roadmap at some point.
Also nice to hear that qnx6 is getting faster. The cost of a chkfsys is hard for us to gauge because our systems
typically run for many months between reboots. So the real worry is that a filesystem corruption might not be detected
for quite some time, which is a much bigger concern.
for what it's worth, we've essentially converted to using fast SSDs (e.g., Intel X25-E) instead of hard drives because
of the high transaction rate we're dealing with these days. How does qnx6 compare when seek time is not an issue?
Thanks,
lew
|
|
|
|
|
|
John Garvey
07/21/2009 7:13 PM
post34274
|
Lewis Donzis wrote:
> for what it's worth, we've essentially converted to using fast SSDs (e.g., Intel X25-E) instead of hard drives because
of the high transaction rate we're dealing with these days. How does qnx6 compare when seek time is not an issue?
Sorry, I have not been able to do an analysis/benchmark, or even
best-practice configuration hints, for SSD. So all I can suggest
is "SDD is not HDD", and that care and attention must be paid to
the supplier for the flash controller smarts (eg wear levelling),
especially if MLC is used, since you're at the mercy of those
(generally proprietary) algorithms for performance and robustness.
Anecdotally, 'mkqnx6fs -b4k', a large 'blk cache=' and increased
'blk delwri=' and 'qnx6 snapshot=' times seem indicated; having
the devb driver report a 2k or 4k sector (to match NAND page width)
is also likely to be beneficial.
|
|
|
|
|
|
Mario Charest
07/21/2009 7:16 PM
post34275
|
I have taken a quick look at implementing a TRIM command, because for modern SSD it's going to be important. Didn't get
very far ;-(
I have been using a OCZ Vertex and they scream. Under Windows I can keep it running fast with an utility that sends a
TRIM. Under QNX6 at 32Gig they are way bigger then we need them for, so we haven't run into slow down issue yet, but
it's going to happen at one point in time.
-----Original Message-----
From: John Garvey [mailto:community-noreply@qnx.com]
Sent: Tuesday, July 21, 2009 7:13 PM
To: general-filesystems
Subject: Re: >4GB file support
Lewis Donzis wrote:
> for what it's worth, we've essentially converted to using fast SSDs (e.g., Intel X25-E) instead of hard drives because
of the high transaction rate we're dealing with these days. How does qnx6 compare when seek time is not an issue?
Sorry, I have not been able to do an analysis/benchmark, or even
best-practice configuration hints, for SSD. So all I can suggest
is "SDD is not HDD", and that care and attention must be paid to
the supplier for the flash controller smarts (eg wear levelling),
especially if MLC is used, since you're at the mercy of those
(generally proprietary) algorithms for performance and robustness.
Anecdotally, 'mkqnx6fs -b4k', a large 'blk cache=' and increased
'blk delwri=' and 'qnx6 snapshot=' times seem indicated; having
the devb driver report a 2k or 4k sector (to match NAND page width)
is also likely to be beneficial.
_______________________________________________
General
http://community.qnx.com/sf/go/post34274
|
|
|
|
|
|
Mario Charest
07/21/2009 10:15 AM
post34191
|
May not be the target market but with 1Tbytes HD at 99$ it sounds to me like having trouble find HD smaller than 2TB is
not that far off. The company I work for supports 10 year old system ;-)
But if devb-* can use the first 2Tbytes of a 4Tbytes HD I guess it's not too bad.
-----Original Message-----
From: John Garvey [mailto:community-noreply@qnx.com]
Sent: Tuesday, July 21, 2009 1:13 AM
To: general-filesystems
Subject: Re: >4GB file support
Lewis Donzis wrote:
The (internal devb) disk API remains a 32-bit blkno, which limits to
2TB HDD, and there was no attempt to consider potential expansion, as
that's not really my (our?) target market. Maybe something like that?
|
|
|
|
|
|
Mario Charest
07/21/2009 10:09 AM
post34189
|
-----Original Message-----
From: Lewis Donzis [mailto:community-noreply@qnx.com]
Sent: Tuesday, July 21, 2009 12:44 AM
To: general-filesystems
Subject: Re: >4GB file support
Thanks for the quick reply.
That's great to hear that qnx6 is 64-bit, sorry for the misunderstanding.
Just in case: The filesystem (qnx6fs) is 64 bit not the operating system(qnx6)!
_______________________________________________
General
http://community.qnx.com/sf/go/post34149
|
|
|
|
|
|
Lewis Donzis
|
Re: RE: >4GB file support
|
|
Lewis Donzis
07/21/2009 11:13 AM
post34207
|
Re: RE: >4GB file support
> Just in case: The filesystem (qnx6fs) is 64 bit not the operating system(qnx6)
Sorry, I knew what you meant, just forgot to type the "fs" part! :)
lew
|
|
|
|
|
|
