Amiga.org
Amiga computer related discussion => General chat about Amiga topics => Topic started by: SHADES on June 10, 2011, 11:21:07 AM
-
Just wondering if anyone is working on PFS3 to enable big TB partitions for big fast drives etc.....
Just such a shame if it has now been released and no one is interested. Such a great FS.
-
Just wondering if anyone is working on PFS3 to enable big TB partitions for big fast drives etc.....
Just such a shame if it has now been released and no one is interested. Such a great FS.
Yes, Piru is working on it! :)
EDIT: Here are some posts from him about the progress:
http://www.morphzone.org/modules/newbb_plus/viewtopic.php?forum=3&topic_id=7805
-
You can follow the progress here: http://pfs-amiga.svn.sourceforge.net/viewvc/pfs-amiga/
-
Just wondering if anyone is working on PFS3 to enable big TB partitions.
Enabling larger partitions is a bit tricky. There are some notes about it here:
http://sourceforge.net/tracker/?func=detail&aid=3285711&group_id=532591&atid=2163218 (click comment)
See here for the full list of feature requests:
http://sourceforge.net/tracker/?group_id=532591&atid=2163218
As for the progress: PowerPC native PFS3 is working on MorphOS now.
-
Just wondering if anyone is working on PFS3 to enable big TB partitions for big fast drives etc.....
Just such a shame if it has now been released and no one is interested. Such a great FS.
If you're really looking to work with TB sized partitions the I'd recommend SmartFileSystem as there is no limitation on partition size or HD size... :)
I've been using it for many years now and it has proven very stable and I have never lost one bit of data with it... :)
SmartFileSystem Ver 1.279 (http://strohmayer.org/)
-
If you're really looking to work with TB sized partitions the I'd recommend SmartFileSystem as there is no limitation on partition size or HD size.
SFS is dog slow compared to PFS3 though. Also there for sure is a limitation of 2TB, so there's no use in getting a HDD larger than that.
-
SFS is dog slow compared to PFS3 though. Also there for sure is a limitation of 2TB, so there's no use in getting a HDD larger than that.
Slow is just your opinion Piru and of course your entitled to that... :)
But you are very wrong in saying that is has a 2TB limitation, I suggest you download it read the docs and better still try it for yourself and you will find you are totally wrong with your 2TB limitation claim... :)
Looks like you don't know everything after all... ;)
-
Slow is just your opinion Piru and of course your entitled to that.
Actually it isn't an opinion but fact that can be verified by anyone.
But you are very wrong in saying that is has a 2TB limitation
The limitation is 2TB.
-
Actually it isn't an opinion but fact that can be verified by anyone.
The limitation is 2TB.
Again it's just an opinion and just to prove you wrong here's my opinion "SFS is fast"... :)
so there you go, you did say anyone and I being anyone have just told you that it is fast and verified by me but at the end of it all no matter what you or I say it's simply an opinion... :)
Now where your totally wrong is in your claim that 2TB is the limit on SFS which I can tell you straight is absolutely wrong... :)
And as you were forever telling others like Dave Haynie to back things up they say, well now it's your turn. Back up this incorrect/false claim of a 2TB limit or stop making such false claims as you often like to tell others... ;)
-
Again it's just an opinion and just to prove you wrong here's my opinion "SFS is fast"... :)
so there you go, you did say anyone and I being anyone have just told you that it is fast and verified by me but at the end of it all no matter what you or I say it's simply an opinion... :)
He said it's slow compared to PFS.
One of them is faster than the other, that is a fact. It's not an opinion if there are cold hard facts.
-
He said it's slow compared to PFS.
One of them is faster than the other, that is a fact. It's not an opinion if there are cold hard facts.
It may be a "Fact" to Piru and yourself but I beg to differ I say SFS is fast and again it's all down to opinions, nothing else... :)
Strange how he can't provide proof of his absurd 2TB limit claim (which he has posted twice now), as I await here to prove him wrong with proof that there is no such 2TB limit using SFS... ;)
And for anyone who does not want to wait on Pirus answer (if he ever gives one) then feel free to go to the authors site and download SFS and read the docs and see for themselves that Pirus 2TB Limit claim is wrong... ;)
SmartFileSystem Ver 1.279 (http://strohmayer.org/)
-
So, where exactly can I download a nice precompiled and user-friendly release of this new open-source version?
btw: if Piru recommends something Amiga related, I'd (personally) take his word as gospel.
-
btw: if Piru recommends something Amiga related, I'd (personally) take his word as gospel.
Then more fool you as SFS doesn't have the filesize or HD size limitations that PFS3 does... ;)
-
I can't agree or disagree on the point of filesize limits, but I'm not at all interested in filesize limits. Speed on my A1200 is the most important factor and I remember that a few years back (when deciding between the two) PFS3 was the clear winner.
As for taking Piru's word on Amiga issues, I do not think that is foolish. Piru has proven over the years that he knows the Amiga system inside out. Even if he made a mistake on the filesize limit - it's simply because he's human (despite what some may think, lol) ;)
anyway, i will not get tangled up in this. :)
-
From what i've read, the source code that was released is for version 18.3.
There was an important bugfix in 18.5 that is needed for Apache to work. Is that fix existing in the source code at sourceforge.net?
-
It may be a "Fact" to Piru and yourself but I beg to differ I say SFS is fast and again it's all down to opinions, nothing else... :)
SFS stops being fast when admin blocks are cluttered over the disk. Performance degrades faster if you are using .recycled directory but reality is that newly formatted SFS disk is always faster than old empty SFS disk.
-
Then more fool you as SFS doesn't have the filesize or HD size limitations that PFS3 does... ;)
SFS partitions are limited to 127GB and filesize can not be larger than 2GB. In theory you can have file size to almost 4GB but it is not guaranteed to work with all applications.
-
Slow is just your opinion Piru and of course your entitled to that.
I guess it's the opinion of the several Amigas I own, too. In addition to being subjectively faster by an obvious measure, the PFS3 partitions always booted faster by several seconds and won all the filesystem related tests and benchmarks.
This is on everything from A1200 and A4000 internal IDE, to accelerator SCSI on my GVPA530, TekMagic 2060, CS-MK2, CSPPC, and finally USB drives off the DENEB. I also have a vague recollection of PFS3 blowing away SFS on my old Pegasos (but that was a long time ago).
No data loss either since I purchased it sometime in the late 90's, including testing some purposefully flaky setups.
-
SFS is dog slow compared to PFS3 though. Also there for sure is a limitation of 2TB, so there's no use in getting a HDD larger than that.
And filesystem limitations aside, IIRC 2.5TB drives and above use 4k physical block sizes. I know this is a problem for some PCs, but I'm not certain about the Amiga.
-
SFS partitions are limited to 127GB and filesize can not be larger than 2GB. In theory you can have file size to almost 4GB but it is not guaranteed to work with all applications.
Sorry mate but your 100% wrong on both claims... :)
With the introduction in SFS of SF2 partitions the 127GB limitation was done away with a number of years ago along with the 4GB filesize... :)
With an SF2 partition there is on limit in theory as to the partition size or filesize... :)
Hence the reason why on my 2 500GB Amiga HDs I have 250Gb partitions crammed full of DVD Dual Layer ISO's of up 8.3GB individual file sizes and all can be read or written on the Amiga without any problems whatsoever and I've been doing this on a daily basis for a number of years now without any problems or loss of data... :)
I suggest to all who like to make these false claims to download SmartFileSystem themselves and read carefully the docs and better still try it out for themselves before making such incorrect statement and claims here... :)
-
newly formatted SFS disk is always faster than old empty SFS disk.
I have some vague memories about reading somewhere that some zones of the HD (when sectors are written at the borders) are faster than others -inner ones- (but I may be wrong)
BTW, nothing to argue against PFS3 vs SFS performance, I just hope it jumps to 64bit soon so we can enjoy bigger HDs and >4GB files with it too. I use ext2 due to big files and my partitions are formatted as SFS so I doubt I*switch soon-ish
-
Franko: You just love to piss off Piru don't you? :)
-
From what i've read, the source code that was released is for version 18.3.
There was an important bugfix in 18.5 that is needed for Apache to work. Is that fix existing in the source code at sourceforge.net?
See http://sourceforge.net/tracker/?func=detail&aid=3285730&group_id=532591&atid=2163218
The filesystem itself should be pretty much in par with 18.5 now, except that it's actually even better (several serious bugs have been fixed).
-
RDB can only handle 32bit sector numbers. Unless if we ditch RDB for GPT (or similar) we're limited to 2TB disks.
In addition TD_GETGEOMETRY is limited to 32bit sector count:
ULONG dg_TotalSectors; /* total # of sectors on drive */
There's nothing a filesystem can do about this. And before anyone asks, no, adjusting your block size for the filesystem will not help here.
-
Franko: You just love to piss off Piru don't you? :)
Nope... believe it or not I actually think Piru gives out some very useful and helpful advice, just when he's wrong about something he seems to lack the ability to admit it... :)
And in this case anyone can easily download SmartFileSystem from the link I gave and test it for themselves to see that no matter what Piru says on this subject he is just simply wrong... :)
-
Franko: I could never get SFS to work. I have heard it is faster and more flexable than FFS, but have never heard anyone but you claim that it was better than PFS, which I am currently using.
On that note, I can say that PFS is NO FASTER than FFS when used with a CF Card via IDE adaptor. My A600 030 still opens directories at the same slow speed at 16 Colors, though I can at least use larger partitions now, so I'm half way happy at least. :)
Piru: Are there any advantages to me updating my MorphOS partitions to PFS over the default file system that MorphOS uses during an install?
-
Piru: Are there any advantages to me updating my MorphOS partitions to PFS over the default file system that MorphOS uses during an install?
Assuming your HDD uses RDB and it's thus possible to use PFS3...
Yes. Even the 68k PFS3 is a lot faster than SFS.
Later on PFS3 will be included in MorphOS itself, too.
-
And in this case anyone can easily download SmartFileSystem from the link I gave and test it for themselves to see that no matter what Piru says on this subject he is just simply wrong... :)
Tell me, how many >2TB hard disks have you partitioned with an amiga?
-
Franko: I could never get SFS to work. I have heard it is faster and more flexable than FFS, but have never heard anyone but you claim that it was better than PFS, which I am currently using.
On that note, I can say that PFS is NO FASTER than FFS when used with a CF Card via IDE adaptor. My A600 030 still opens directories at the same slow speed at 16 Colors, though I can at least use larger partitions now, so I'm half way happy at least. :)
Piru: Are there any advantages to me updating my MorphOS partitions to PFS over the default file system that MorphOS uses during an install?
That's simply because fewer folk have heard of SFS let alone given the last version released (Ver 1.279) a try. I've used PFS myself but it's filesize limitation was my main reason for switching to SFS as I need to be able to read & burn full DVD ISO images (ie bigger than 4GB) on my Amiga's... :)
Whether I'm the only person to say it's more flexible doesn't matter to me, the point is it works and can do the stuff I require which PFS can't do... :)
-
Tell me, how many >2TB hard disks have you partitioned with an amiga?
None... as the biggest drives I use are 1TB... :)
Now you tell me after you've given SFS Ver 1.279 a try on an Amiga that it has a 2TB limitation... ;)
-
So, where exactly can I download a nice precompiled and user-friendly release of this new open-source version?
Nowhere as of yet. For now you should use the PFS3 binary version uploaded to aminet.
If you really MUST have the latest goodies you need to build it by yourself. For 68k version you need SAS/C and the amiga NDK 3.x. You also need to install the multiuser.library SDK if you wish to build the multiuser version.
However I'd advice against using the development PFS3 version in a production environment. Things can be in a slight flux there.
-
Now you tell me after you've given SFS Ver 1.279 a try on an Amiga that it has a 2TB limitation... ;)
I don't need to test it. I know it's technically impossible to partition a >2TB drive reporting 512 byte block size (that's what current drives do due to compatibility reasons). These drives will report more than 2^32-1 sectors and you cannot fit such number into 32bit data type (used by both TD_GETGEOMETRY and RDB itself).
-
I don't need to test it. I know it's technically impossible to partition a >2TB drive reporting 512 byte block size (that's what current drives do due to compatibility reasons). These drives will report more than 4^32-1 sectors and you cannot fit such number into 32bit data type (used by both TD_GETGEOMETRY and RDB itself).
Wrong... yet again... no one said anything about using 512 byte block sizes... :)
Do us both a favour go read the docs and send you theories to the author of SFS, it works (don't ask me how, ask the author) it's as plain and simple as that... ;)
-
Wrong... yet again... no one said anything about using 512 byte block sizes... :)
You cannot change the block size the drive uses internally. Logical block size used with filesystem is irrelevant here.
Do us both a favour go read the docs
Any amount of reading the docs won't change the fact that it's impossible to RDB partition a >2TB drive reporting 512 byte block size. If the documentation claims otherwise it is in error. You do realize that the documentation might not be entirely accurate?
send you theories to the author of SFS
The real author of SFS is doing some other things these days. For some reason the project was hijacked by this strohmayer guy. Regardless, both would agree with my assessment. As will anyone who can understand simple math.
-
You cannot change the block size the drive uses internally. Logical block size used with filesystem is irrelevant here.
Any amount of reading the docs won't change the fact that it's impossible to RDB partition a >2TB drive reporting 512 byte block size.
The real author of SFS is doing some other things these days. For some reason the project was hijacked by this strohmayer guy. Regardless, both would agree with my assessment.
Piru dear chap... all I can say to you is YOU ARE TOTALLY WRONG and unless you give it a try yourself then you can post all the technical mumbo jumbo you want, it still doesn't change the FACT IT WORKS... :)
So unless you decide to actually try it for yourself and then come back to me with proof that it doesn't work, then you can go on quoting all the figures you want till your blue in the face, at the end of the day you are quite simply wrong on this one and I will quite happily tell you so until you prove me wrong... :)
-
Alright Franko. We want screen shots of videos of this proof! This I got to see! :)
-
Alright Franko. We want screen shots of videos of this proof! This I got to see! :)
Screen shots of what ??? video of what ???
PS: In case you hadn't noticed or conveniently missed it Piru is the one claiming this 2TB limit and it's up to him to prove his claim not me... :)
Course I have provided a link where anyone can download SFS so if your too lazy to download it, read the docs or even try for yourself then I sure as hell aint wasting my time proving something someone else said... :)
-
you can post all the technical mumbo jumbo you want
It actually is quite relevant technical information that explains in simple terms why I am right. You can of course try to deny it all you want, but it still doesn't change the facts presented.
You on the other hand seem to base your claim on the dubious remarks in the documentation: "Supports large partitions. The limit is about 2000 GB, but it can be more depending on the blocksize." and "With this new 'SFS\2' format it's possible to create ... partitions larger than 128 GB (the limit for 'SFS\2' partitions is 1 TB * blocksize / 512)."
What the author of that comment doesn't realize is that while the FS might in theory work with larger block size, there is no way to partition >2TB HDD by using RDB. In fact there isn't even a way to query the true capacity of such drive via TD_GETGEOMETRY.
Thus the maximum is in fact limited to 2TB, regardless of the logical block size you might use.
-
Franko: I don't have a drive larger than 2Tb my self, hence the reason I need videos or pictures as proof. Besides, I could never get SFS to work in the first place.
Sorry, man. I have to mess with you, Piru is paying me good money for this! ;)
-
It actually is quite relevant technical information that explains in simple terms why I am right. You can of course try to deny it all you want, but it still doesn't change the facts presented.
You on the other hand seem to base your claim on the dubious remarks in the documentation: "Supports large partitions. The limit is about 2000 GB, but it can be more depending on the blocksize." and "With this new 'SFS\2' format it's possible to create ... partitions larger than 128 GB (the limit for 'SFS\2' partitions is 1 TB * blocksize / 512)."
What the author of that comment doesn't realize is that while the FS might in theory work with larger block size, there is no way to partition >2TB HDD by using RDB. In fact there isn't even a way to query the true capacity of such drive via TD_GETGEOMETRY.
Thus the maximum is in fact limited to 2TB, regardless of the logical block size you might use.
Ah so you finally bothered to read the docs... :)
A minute ago you were telling me you the author would agree with your assessment, now you've read his docs you are now telling what he says is dubious... :rolleyes:
Again I say to you and this is speaking from my own experience using this filesystem, you go ahead and try it on a >2TB HD and if it doesn't work then I'll happily admit I was wrong and then give the author a roasting for being a diddy, sound fair... :)
-
prove
- TD_GETGEOMETRY and RDB use 32bit unsigned value to store block numbers. The maximum block number they can represent is 2^32 -1 or 4294967295.
- 3TB HDD uses block size of 512(*). The capacity reported is around 3 * 1000 * 1000 * 1000 * 1000 / 512 blocks or 5859375000.
- The value 5859375000 is larger than 4294967295. Thus it cannot be represented with a 32bit unsigned integer data type. Ergo TD_GETMEOMETRY or RDB cannot properly report/handle such device.
(*) Internally these drives use 4KB block size, but due to compatibility reasons they report back 512 byte block size.
-
We need to get you guys drunk and put you in a ring together. This could be fun. Two nerds duking it out! Power Gloves allowed! ;)
-
Franko: I don't have a drive larger than 2Tb my self, hence the reason I need videos or pictures as proof. Besides, I could never get SFS to work in the first place.
Sorry, man. I have to mess with you, Piru is paying me good money for this! ;)
And as I said the largest HD's I've got are 1TB so not much point in making a video of that (course I could doctor the pictures to turn it into a 4TB drive if that'll make everyone happy)... :)
Piru paying out money... aye right... and I'm the Queen of England... :)
-
A minute ago you were telling me you the author would agree with your assessment
He still will. Unless if he's stupid enough not to see the problem.
now you've read his docs you are now telling what he says is dubious...
The claim is misleading. The author doesn't realize or doesn't want to acknowledge that there are limits imposed from elsewhere.
you go ahead and try it on a >2TB HD and if it doesn't work then I'll happily admit I was wrong
I tell you again: There's no need to test it, it will fail at partitioning time.
-
Godamn Pancakes!
-
- TD_GETGEOMETRY and RDB use 32bit unsigned value to store block numbers. The maximum block number they can represent is 2^32 -1 or 4294967295.
- 3TB HDD uses block size of 512. The capacity reported is around 3 * 1000 * 1000 * 1000 * 1000 / 512 blocks or 5859375000.
- The value 5859375000 is larger than 4294967295. Thus it cannot be represented with a 32bit unsigned integer data type. Ergo TD_GETMEOMETRY or RDB cannot properly report/handle such device.
Awe Gawd... more mumbo jumbo, look Piru unlike you I'm not an andriod made of old PC parts running on a flakey version of MorphOS, so you can post all the gobbledegook or Einstein's theories on how space is really a banana and you are I don't really exist, all you want... ;)
I STILL SAY YOUR WRONG... :insane:
-
@Franko
You asked for proof and I provided it. Care to explain how my proof is incorrect?
-
With the introduction in SFS of SF2 partitions the 127GB limitation
Yes but it can corrupt your data. That is at least case with the original SFS and I dont have idea about SFS2 but I dont think it was fixed. I recall Joerg said it was not fixed.
was done away with a number of years ago along with the 4GB filesize... :)
You can not really access files larger than 4GB in OS3. First of all file size of 4GB+ files is reported wrong (have size of 0 bytes) and applications can not seek past 4GB barrier. Some applications might be able to read those files but it is not guaranteed to work.
-
Piru paying out money... aye right... and I'm the Queen of England... :)
No, you are the king of scotland :-)
-
Yes but it can corrupt your data. That is at least case with the original SFS and I dont have idea about SFS2 but I dont think it was fixed. I recall Joerg said it was not fixed.
You can not really access files larger than 4GB in OS3. First of all file size of 4GB+ files is reported wrong (have size of 0 bytes) and applications can not seek past 4GB barrier. Some applications might be able to read those files but it is not guaranteed to work.
Sorry mate but once again your wrong on OS3.1, 3.5 & 3.9 and SFS with SF2 partitions you can indeed read and write files even with the c: command "Copy"... :)
Again I assure you in all the years of using SFS I have not lost one bit of data and applications don't handle the actual data transfer (that's what the file system does)... :)
The only problems you will encounter are application displaying the wrong file size as most were written never expecting to take files of >4GB into account... :)
Heck even OS4.0 came with it's own PPC version of SFS as most apps in that are written to display the correct file and HD size... :)
As I've said before don't knock it till you try it... ;)
-
@Franko
You asked for proof and I provided it. Care to explain how my proof is incorrect?
Cos I said so... simple as... ;)
-
The only problems you will encounter are application displaying the wrong file size as most were written never expecting to take files of >4GB into account... :)
With AmigaOS 3.x that would be all applications. APIs in AmigaOS 3.x can only represent a 32bit number for the file size.
Only applications reading up until EOF will work properly. Any AmigaOS 3.x application that actually queries the file size first before processing that amount of data will fail. Many applications seeking in a file will fail randomly as negative return value from Seek() was commonly considered an error.
Oh I'm sorry for giving you more technically correct and factual information. You may yell "YOU'RE WRONG!" if that makes you feel any better.
-
Sorry mate but once again your wrong on OS3.1, 3.5 & 3.9 and SFS with SF2 partitions you can indeed read and write files even with the c: command "Copy"... :)
Yes that might work indeed. It is not intended behaviour though. Just side effect of Copy command implementation.
Again I assure you in all the years of using SFS I have not lost one bit of data and applications don't handle the actual data transfer (that's what the file system does)... :)
You can. I dont know if it was fixed in OS3 version but there was a bug it could accidentally trash fs admin blocks. Not so annoying than crashing FFS partition though.
The only problems you will encounter are application displaying the wrong file size as most were written never expecting to take files of >4GB into account... :)
OS3 applications can never display file size correctly. It just isnt possible.
Heck even OS4.0 came with it's own PPC version of SFS as most apps in that are written to display the correct file and HD size... :)
I have never seen it so cant comment.
As I've said before don't knock it till you try it... ;)
I have been using SFS since version 1.52 from 1998 and all my partitions are SFS still. Wrote small app for it long ago. I never had PFS.
-
With AmigaOS 3.x that would be all applications. APIs in AmigaOS 3.x can only represent a 32bit number for the file size.
Only applications reading up until EOF will work properly. Any AmigaOS 3.x application that actually queries the file size first before processing that amount of data will fail. Many applications seeking in a file will fail randomly as negative return value from Seek() was commonly considered an error.
Easy example DirWork V2.1 written in 1994/95, like I say things display the wrong file size but they copy perfectly without errors, on DirWork (or DOpus for that matter) they can easily copy an 8.3GB DVD ISO from one partition to the other without any problems... :)
All I know is it work for me, I'm not interested in the technical details of how it works. It does what is required without error and for me that's all that matters... :)
Sorry but I'm not the type who cares how many nanoseconds it takes for something to do something or how many transistors will fit on the latest CPU or why my grannies bloomers always fell down due the fact that the consistency of the elastic in them was wrong... :)
Me I'm just happy that things work for me on my Amiga's the way I need them to and that makes me happy & satisfied... :)
PS:You've made me miss getting a home delivery from the Chippy as it's now midnight, now I'm gonna have to go and cook something instead before I sit down to watch Friday Night Smack Down where at least I can relax watching something a wee bit more intelligent than all this mind numbing stuff... :furious:
-
I have been using SFS since version 1.52 from 1998 and all my partitions are SFS still. Wrote small app for it long ago. I never had PFS.
Then you should really download the last version written from the link I posted it's far better than all the earlier versions... :)
-
- TD_GETGEOMETRY and RDB use 32bit unsigned value to store block numbers. The maximum block number they can represent is 2^32 -1 or 4294967295.
- 3TB HDD uses block size of 512(*). The capacity reported is around 3 * 1000 * 1000 * 1000 * 1000 / 512 blocks or 5859375000.
- The value 5859375000 is larger than 4294967295. Thus it cannot be represented with a 32bit unsigned integer data type. Ergo TD_GETMEOMETRY or RDB cannot properly report/handle such device.
You'd actually need 43 bits to represent that value (unsigned). Logarithms FTW ;)
-
You'd actually need 43 bits to represent that value (unsigned). Logarithms FTW ;)
Don't you ruddy well start... :furious:
-
You'd actually need 43 bits to represent that value (unsigned). Logarithms FTW ;)
Actually 33 bits (http://www.wolframalpha.com/input/?i=lg2%283+*+1000+*+1000+*+1000+*+1000+%2F+512%29). TD_GETGEOMETRY and RDB use block offsets, not byte offsets.
-
Actually 33 bits (http://www.wolframalpha.com/input/?i=lg2%283+*+1000+*+1000+*+1000+*+1000+%2F+512%29). TD_GETGEOMETRY and RDB use block offsets, not byte offsets.
That's bizarre, I just did the exact same calculation on my CFX-9850G+ and it comes to 33 (as above), but when I did it the first time, it came to 43. I wonder what the hell I missed out? Even neglecting the /512 leaves you with 42 when rounded up :)
-edit-
I probably got 42 the first time and chucked on an extra bit to ensure sign couldn't be an issue.
-
Awe Gawd... more mumbo jumbo, look Piru unlike you I'm not an andriod made of old PC parts running on a flakey version of MorphOS, so you can post all the gobbledegook or Einstein's theories on how space is really a banana and you are I don't really exist, all you want... ;)
I STILL SAY YOUR WRONG... :insane:
Just to clear things up a bit. I was the one who built Piru. I used parts from some old desktopp 286's and 386's I had laying around in the shed that I now use to store the children I kidnap and kill.
For the note, he does not run on a flaked out version of MorphOS as there is no such thing. Rather he is operated by a series of metallic strings which are attached to piano keys which I use to control his movement. If he seems to lack a sense of humour, that is because his humour chip was destroyed in the tragedy that was Star Trek Generations.
In relation to all the code he has written...
That again is all me. I just give my Piru bot credit in the event that someone would wish to critique my hard work... in which case all their anger will be directed at him and not me.
KarlOS on the other hand is my 2nd Generation model made mostly of Lego Machines driven by Hamsters in wheels. I is my writer's alias for all the OS4 code I'm doing.
-
We need to get you guys drunk and put you in a ring together. This could be fun. Two nerds duking it out! Power Gloves allowed! ;)
Showing your age, man. It'd be Wii Boxing, now.
-
Showing your age, man. It'd be Wii Boxing, now.
Alright, to show my age I'll suggest that they can bash each other over the heads with old Pong Home consoles if they wish! That or they can attempt to drive 2600 joysticks into one another's eye sockets.
-
Franko doesn't need any more alcohol.
-
- TD_GETGEOMETRY and RDB use 32bit unsigned value to store block numbers. The maximum block number they can represent is 2^32 -1 or 4294967295.
- 3TB HDD uses block size of 512(*). The capacity reported is around 3 * 1000 * 1000 * 1000 * 1000 / 512 blocks or 5859375000.
But is TD_GETGEOMETRY really required to return the same block size as reported by the drive or can it return a fake one (multiple of the one reported by drive) for very big drives?
-
1 million years ago today,
the very first caveman Franko met the very first caveman Piru. Here is what happened:
Franko: Ooga
Piru: Uhg
Franko: No. Ooga.
Piru: No. Uhg.
Franko: No. Ooga!
Piru: No. Uhg!
Franko: No! Ooga!!
Piru: No! Uhg!!
Franko: No!! Ooga!!!
Piru: No!! Uhg!!!
Historians consider this initial disagreement (which still continues today) to have kickstarted the evolution of complex linguistics, adjectives, adverbs, prepositional phrases, logical reasoning, binary arithmetic, flowery insults, four-letter words and possibly the invention of alcohol.
:laughing::roflmao: :rofl:
-
1 million years ago today,
the very first caveman Franko met the very first caveman Piru. Here is what happened:
Franko: Ooga
Piru: Uhg
Franko: No. Ooga.
Piru: No. Uhg.
Franko: No. Ooga!
Piru: No. Uhg!
Franko: No! Ooga!!
Piru: No! Uhg!!
Franko: No!! Ooga!!!
Piru: No!! Uhg!!!
Historians consider this initial disagreement (which still continues today) to have kickstarted the evolution of complex linguistics, adjectives, adverbs, prepositional phrases, logical reasoning, binary arithmetic, flowery insults, four-letter words and possibly the invention of alcohol.
:laughing::roflmao: :rofl:
Ha ha ha!!! :)
-
Showing your age, man. It'd be Wii Boxing, now.
Well, there's absolutely no way Franko qualifies as a nerd. So I'm afraid he would be immediately disqualified from any 'nerd fight'.
AH
-
Well I'm not convinced of the need for speed of these new filesystems, if it comes at the expense of stability. if you have a need for big drives I can understand, but 4 gig flash drives work plenty quick on FFS, especially with directory cache and addbuffers.
In my experience with SFS, I've had two massive crashes, one on an IDE-ATA INTERFACE the other cyber SCSI INTERFACE, to the point that I had to resort to an old P2 XPPro system to even recognise the drive afterwards (an athlon x2 MB systme with XP and Vista point blank would not even see the drive), after several attempts, initialise it, format it, put it back in the amiga and format it again. With FFS. Not sure what version of SFS it was, but SFS ain't going back on any drive I own! EVER.
I had a simila experience with PFS2, so I'm not in a hurry to install PFS3 tbh.
-
1 million years ago today,
the very first caveman Franko met the very first caveman Piru. Here is what happened:
Franko: Ooga
Piru: Uhg
Franko: No. Ooga.
Piru: No. Uhg.
Franko: No. Ooga!
Piru: No. Uhg!
Franko: No! Ooga!!
Piru: No! Uhg!!
Franko: No!! Ooga!!!
Piru: No!! Uhg!!!
Historians consider this initial disagreement (which still continues today) to have kickstarted the evolution of complex linguistics, adjectives, adverbs, prepositional phrases, logical reasoning, binary arithmetic, flowery insults, four-letter words and possibly the invention of alcohol.
:laughing::roflmao: :rofl:
Oi you... Ugh bongo Klub fire burnie Wheeeeel ooga :furious:
PS: As Piru doesn't seem to be up yet then...
I STILL SAY I WAS RIGHT... :D
-
I STILL SAY I WAS RIGHT... :D
You *do* realize that your arguments are like claiming *it's a matter of opinion* whether stones fall down to the ground and not up in space when you drop them, and that the right interpretation of 1+1 is that it equals to 3, right? ;)
-
You *do* realize that your arguments are like claiming *it's a matter of opinion* whether stones fall down to the ground and not up in space when you drop them, and that the right interpretation of 1+1 is that it equals to 3, right? ;)
Nope... and your wrong too... :)
PS: Stones never fall to the ground, as Mick & co are always high as kite and floating up around the ceiling... :)
PPS: Im not "Arguing" I'm "Telling"... ;)
-
Guys, this is getting stupid, arguing for the sake of argument's sake.
Stick to the topic. The question was, is PFS3 being worked on?
MorphOS: Yes, Harry is working on that.
AROS: ?
OS4: ?
OS3: ?
The drive capacity supported by SFS is irrelevant to this discussion, but to offer my 2p worth, if the maximum number of 512K blocks is represented by a 32-bit integer anywhere in the system, then you are definitely out of luck once that integer wraps round. No amount of shouting is going to change that.
-
MorphOS: Yes, Harry is working on that.
AROS: ?
OS4: ?
OS3: ?
Currently almost all changes are generic. Of course the OS3 version is directly benefiting from the changes being made. There's only one SVN tree that has everything. Assuming the file system is ported to AROS and OS4 it'd be highly desirable to have those changes in the same SVN as well.
Anyone wishing to contribute should contact mr Pelt over sourceforge.
-
Currently almost all changes are generic. Of course the OS3 version is directly benefiting from the changes being made. There's only one SVN tree that has everything. Assuming the file system is ported to AROS and OS4 it'd be highly desirable to have those changes in the same SVN as well.
Anyone wishing to contribute should contact mr Pelt over sourceforge.
Sounds good. I was meaning to take a peek myself but I have very little free time presently.
-
You *do* realize that your arguments are like claiming *it's a matter of opinion* whether stones fall down to the ground and not up in space
Well, that's a matter or perspective. If you are out in a UFO watching someone in the U.S. drop a stone, it would be falling up toward outer space in China. Sure, it probably wouldn't make it as it would be blocked by this huge thing called the Earth. But, still, it's falling "toward" space.
:) Sorry, back to the topic. Err, yes it appears PFS3 is being worked on.
-
Well, that's a matter or perspective. If you are out in a UFO watching someone in the U.S. drop a stone, it would be falling up toward outer space in China. Sure, it probably wouldn't make it as it would be blocked by this huge thing called the Earth. But, still, it's falling "toward" space.
:) Sorry, back to the topic. Err, yes it appears PFS3 is being worked on.
Silly me, I totally neglected the UFO perspective! ;) :lol:
-
Silly me, I totally neglected the UFO perspective! ;) :lol:
(http://webservice.imagesauce.net/image/235894/400x.jpg)
-
Currently almost all changes are generic. Of course the OS3 version is directly benefiting from the changes being made.
So what compiler are you using ? I've tried to compile it myself with SAS/C and VBCC, but it only gives me lots of errors of non existing items (IPTR, DOSBase->dl_Root [dl_root only exists in dos/dosextens.i, not .h] , gadgets/progress.h missing). :huh:
-
I like pfs3 more than sfs because it can work even with 68000.
-
So what compiler are you using ?
ppc-morphos-gcc and SAS/C 6.58
I've tried to compile it myself with SAS/C and VBCC
VBCC is unlikely to work. Currently things build with SAS/C and gcc.
but it only gives me lots of errors of non existing items (IPTR, DOSBase->dl_Root [dl_root only exists in dos/dosextens.i, not .h] ,
It builds with SAS/C 6.58 and NDK 3.9 includes at least:
http://www.haage-partner.de/download/AmigaOS/NDK39.lha
gadgets/progress.h missing).
gadgets/progress.h is in pfs-amiga/PFSDoctor/trunk. If you don't want to copy it you can modify the pfs-amiga/PFSDoctor/SCOPTIONS file and add: INCDIR=include: INCDIR=include
-
VBCC is unlikely to work. Currently things build with SAS/C and gcc.
Well, in pfs3.h there's a line which says: '#if defined(__GNUC__) || defined(__VBCC__)'. So I thought it might also be build on VBCC.
It builds with SAS/C 6.58 and NDK 3.9 includes at least:
http://www.haage-partner.de/download/AmigaOS/NDK39.lha
Strangely DOSBase->dl_root is in dosextens.h from NDK3.9, but not in the newer version v 1.170 that says 'Copyright (C) 1985-2005 Hyperion Entertainment VOF and Amiga, Inc.'
gadgets/progress.h is in pfs-amiga/PFSDoctor/trunk.
No. It's not there. Please add.
-
Well, in pfs3.h there's a line which says: '#if defined(__GNUC__) || defined(__VBCC__)'. So I thought it might also be build on VBCC.
Well, I don't know if it does. All I know is that it does build with gcc and SAS/C.
Strangely DOSBase->dl_root is in dosextens.h from NDK3.9, but not in the newer version v 1.170 that says 'Copyright (C) 1985-2005 Hyperion Entertainment VOF and Amiga, Inc.'
I see, Hyperion is at it again breaking legacy compatibility. I'd recommend you do NOT use OS4 includes then.
No. It's not there. Please add.
Hmm, I guess I have it there locally then. There are some uncommitted changes in the 68k build since I didn't want to touch those in too many ways.
The official build instructions are in the README file. I think you'd better follow those instructions.
-
The official build instructions are in the README file. I think you'd better follow those instructions.
I've now managed to (almost) build everything (still need trace.lib, dunno why), :insane: except pfsdoctor. And it seems to work..... :)
Deutsch, english, frans and italiano directories still missing from trunk though.
BTW RESNUM should be higher than 5.0 and for this version 'BETAVERSION' should be defined
-
Is there any chance of finally having a 'real' pfs3 defragmenter?
-
Is there any chance of finally having a 'real' pfs3 defragmenter?
Yeah... like ReOrg for FFS with GUI and progress display. That would be really
the finishing touch!
-
Currently almost all changes are generic. Of course the OS3 version is directly benefiting from the changes being made. There's only one SVN tree that has everything. Assuming the file system is ported to AROS and OS4 it'd be highly desirable to have those changes in the same SVN as well.
Anyone wishing to contribute should contact mr Pelt over sourceforge.
Very glad to to see porogress Piru.Tell michael to fix the donate button on the page.
-
SFS stops being fast when admin blocks are cluttered over the disk. Performance degrades faster if you are using .recycled directory but reality is that newly formatted SFS disk is always faster than old empty SFS disk.
Just for interest sake.
Some performance stats testing I did on newly created, freshly formatted partitions on my A4000 FastlaneZ3 SCSI equipped PC.
SFS should be at its fastest this way. PFS still kills SFS in speed.
PFS3020ds
MKSoft DiskSpeed 4.2 Copyright © 1989-92 MKSoft Development
------------------------------------------------------------
CPU: 68030 AmigaOS Version: 45.57 Normal Video DMA
Device: hd2: Buffers: 250
Comments: DiskSpeed 4.2
CPU Speed Rating: 1521
Testing directory manipulation speed.
File Create: 61 files/sec | CPU Available: 8%
File Open: 147 files/sec | CPU Available: 1%
Directory Scan: 1023 files/sec | CPU Available: 0%
File Delete: 149 files/sec | CPU Available: 9%
Seek/Read: 507 seeks/sec | CPU Available: 0%
PFS3020ds (With Increased buffers)
MKSoft DiskSpeed 4.2 Copyright © 1989-92 MKSoft Development
------------------------------------------------------------
CPU: 68030 AmigaOS Version: 45.57 Normal Video DMA
Device: hd0: Buffers: 512
Comments: DiskSpeed 4.2
CPU Speed Rating: 1522
Testing directory manipulation speed.
File Create: 92 files/sec | CPU Available: 8%
File Open: 146 files/sec | CPU Available: 0%
Directory Scan: 1024 files/sec | CPU Available: 0%
File Delete: 149 files/sec | CPU Available: 7%
Seek/Read: 508 seeks/sec | CPU Available: 0%
SFS/2 (With Increased buffers to 600)
MKSoft DiskSpeed 4.2 Copyright © 1989-92 MKSoft Development
------------------------------------------------------------
CPU: 68030 AmigaOS Version: 45.57 Normal Video DMA
Device: hd1: Buffers: 600
Comments: DiskSpeed 4.2
CPU Speed Rating: 1521
Testing directory manipulation speed.
File Create: 61 files/sec | CPU Available: 3%
File Open: 133 files/sec | CPU Available: 2%
Directory Scan: 668 files/sec | CPU Available: 0%
File Delete: 21 files/sec | CPU Available: 2%
Seek/Read: 78 seeks/sec | CPU Available: 0%
SFS/2 (Only 100 buffers)
MKSoft DiskSpeed 4.2 Copyright © 1989-92 MKSoft Development
------------------------------------------------------------
CPU: 68030 AmigaOS Version: 45.57 Normal Video DMA
Device: hd1: Buffers: 100
Comments: DiskSpeed 4.2
CPU Speed Rating: 1520
Testing directory manipulation speed.
File Create: 56 files/sec | CPU Available: 3%
File Open: 132 files/sec | CPU Available: 0%
Directory Scan: 668 files/sec | CPU Available: 0%
File Delete: 44 files/sec | CPU Available: 10%
Seek/Read: 77 seeks/sec | CPU Available: 0%
-
Yeah... like ReOrg for FFS with GUI and progress display. That would be really
the finishing touch!
Maybe someone can ask Dave Haynie if he feels up for it ;)
-
Maybe someone can ask Dave Haynie if he feels up for it ;)
It would be very nice if he would accomplish this! :biglaugh: But the chances are really zero. :(
Maybe some other smart person will make such a program... ;)
-
It would be very nice if he would accomplish this! :biglaugh: But the chances are really zero. :(
Maybe some other smart person will make such a program... ;)
Dave Hanie is a hardware engineer not a magician damn it Jim.
-
Dave Hanie is a hardware engineer not a magician damn it Jim.
He did make DiskSalv though... He doesn't have to be a magician for that! ;)
-
I don't need to test it. I know it's technically impossible to partition a >2TB drive reporting 512 byte block size (that's what current drives do due to compatibility reasons). These drives will report more than 2^32-1 sectors and you cannot fit such number into 32bit data type (used by both TD_GETGEOMETRY and RDB itself).
hm, I wonder if that compatibility mode could be turned off;
because, with 4096 byte blocks, the limit would be 8*2Gb ?
I mean at least some new OS/software would be able to use largest drives without requiring new controllers?
plus the drives might be a bit faster.
-
Pfs3ds_000 v18.4
- 68000+
- Compiled with SAS/C 6.58
- Last version by Harry Sintonen
Here : http://eab.abime.net/showpost.php?p=762029&postcount=96
-
@Piru
This new version of Pfs3 give uninitialised partitions beyond the 4 Gb border : "Write Error -3 on block 0" when used with the scsi 43.45 (Boing Bag 2) burned on eprom...
I'll try with the v18.5 on Aminet, but I think I'll get the same result !
!
-
v18.3ds on Aminet => All partitions are working fine
v18.4ds => All partitions beyond the 4 Gb border are uninitialised
v18.5ds => All partitions beyond the 4 Gb border are uninitialised
(CF 16 Gb on A600 with ACA030 used with the scsi v43.45 into an eeprom)
-
@Cosmos
Use the bug tracker, please. Also, please include output from check4gb (http://aminet.net/package/disk/misc/check4gb).
-
I cannot register on SourceForge : "Username must begin with a letter"...
check4gb
-
@Piru
This new version of Pfs3 give uninitialised partitions beyond the 4 Gb border : "Write Error -3 on block 0" when used with the scsi 43.45 (Boing Bag 2) burned on eprom...
For whatever reason this device doesn't appear to have a working HD_SCSICMD interface (DirectSCSI). This is indicated by the Check4GB output as well (no S).
This doesn't explain why old PFS3 supposedly works. I suspect some problem with your testing method rather than that the old PFS3 would actually be working.
-
Unbelievable... The v18.3 is working fine, YOU made some changes and bump to v18.4...
v18.4 give now partitions uninitialised beyond the 4 Gb border, and it's ME the culprit... Whaou...
Whaou, whaou, whaou...
-
Unbelievable... The v18.3 is working fine, YOU made some changes and bump to v18.4...
I did not bump the filesystem version.
2 michielp #define REVISION "18.4"
2 michielp #define REVDATE "11.09.99"
2 michielp #define REVTIME "18:02:53"
2 michielp #define AUTHOR "Michiel Pelt"
2 michielp #define VERNUM 18
2 michielp #define REVNUM 4
v18.4 give now partitions uninitialised beyond the 4 Gb border, and it's ME the culprit...
v18.5 is the official PFS3 without any of my changes. If it fails then I can't see how this could be my fault.
Finally: The svn version is a work in progress. Anyone using this snapshot is doing so with the knowledge that things may be in flux. I strongly suggest you avoid using random svn builds and rather use the official v18.5 for now.
-
used with the scsi 43.45 (Boing Bag 2)
Really? Isn't that 43.45 some unofficial patch from aminet?
http://aminet.net/package/driver/media/SCSI4345p
THIS PATCH IS COMPLETELY UNOFFICIAL. IT HAS NOT BEEN APPROVED BY AMIGA INC.
OR BY HAAGE & PARTNER. BY USING IT ON YOUR SYSTEM, YOU ACCEPT THE ENTIRE
RISK AS TO ITS QUALITY AND PERFORMANCE.
-
I believed the src version on Aminet was v18.3... My mistake, it's the v18.4...
When coders add some new changes on some sources, they bump the version or the revision numbers...
Anyway, the v18.4 on Aminet compiled with SAS/C 6.58 give the same error than the last files updated on SourceForge...
-
So the conclusion is that this is not Piru's fault.
Correct?
-
Yes !
Pfs3 versions uploaded on Aminet in 2011 :
- binaries => v18.3
- sources => v18.4
-
When coders add some new changes on some sources, they bump the version or the revision numbers...
The source committed to SVN was for earlier PFS3 version (iirc PFS3 5.2 aka 18.4), since the very last src were lost. The source code has since been brought up to date and the current SVN should match the PFS3 5.3 (18.5) in features. See here: http://sourceforge.net/tracker/?func=detail&aid=3285730&group_id=532591&atid=2163218
The SVN "trunk" version is work in progress (and as such the revision hasn't been touched yet). The SVN trunk version isn't guaranteed to be stable at any given moment. Obviously there's nothing we can do to prevent anyone from releasing snapshot builds, but I would appreciate it if any such release would be accompanied with a warning about it being only a snapshot build.
-
Pfs3 versions uploaded on Aminet in 2011 :
- binaries => v18.3
- sources => v18.4
http://aminet.net/package/disk/misc/PFS3_53 contains v18.5 though.
-
The source committed to SVN was for earlier PFS3 version (iirc PFS3 5.2 aka 18.4)
Well, you might wanna bring RELNUM up-to-date. Currently it's still at 5.0.
The SVN "trunk" version is work in progress (and as such the revision hasn't been touched yet). The SVN trunk version isn't guaranteed to be stable at any given moment. Obviously there's nothing we can do to prevent anyone from releasing snapshot builds, but I would appreciate it if any such release would be accompanied with a warning about it being only a snapshot build.
So why not add an alpha or beta definition in the svn, like #define RELNUM "5.2 Beta" (or Alpha), which I did in my copy (unreleased though).