flat assembler
Message board for the users of flat assembler.

Index > Heap > what filesystem are you using & preferred ?

Goto page 1, 2, 3  Next
Author
Thread Post new topic Reply to topic
sleepsleep



Joined: 05 Oct 2006
Posts: 8975
Location: ˛                             ⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣Posts: 334455
sleepsleep
windows u got mainly
NTFS, FAT32, FAT16

linux u got a dozen of choices.
ext3, ext2, reiserfs, jfs, xfs

which one asm programmer use? and any notable reasons
Post 04 Jun 2008, 19:08
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17350
Location: In your JS exploiting you and your system
revolution
I use the default offered by whatever OS I'm using, which means NTFS currently.

Reason: I don't really care about the FS, as long as it keeps my files without error.

If I had a need to dual boot then I might use FAT32. But the FATs are not journalling so you have a higher risk of data loss.
Post 04 Jun 2008, 19:16
View user's profile Send private message Visit poster's website Reply with quote
mattst88



Joined: 12 May 2006
Posts: 260
Location: South Carolina
mattst88
revolution wrote:
If I had a need to dual boot then I might use FAT32. But the FATs are not journalling so you have a higher risk of data loss.


ntfs3g has really made FAT32 useless as a shared-partition filesystem. NTFS read/write support is excellent thanks to ntfs3g on Linux, BSD, Mac OS X, Haiku...

I use ext3 on my systems. The only real reason is because I haven't found a compelling reason to use anything else, with one exception. Reiser is excellent with small files, and therefore is the best choice for Gentoo's portage cache.

As far as a filesystem for assembly programmers... it doesn't really matter. Reiser may be best since it is hands down best at dealing with files smaller than 1 KiB.

_________________
My x86 Instruction Reference -- includes SSE, SSE2, SSE3, SSSE3, SSE4 instructions.
Assembly Programmer's Journal
Post 05 Jun 2008, 02:11
View user's profile Send private message Visit poster's website Reply with quote
sylwek32



Joined: 27 Apr 2006
Posts: 339
sylwek32
UFS2 with Soft Updates. Background Filesystem scans are nice.
Post 05 Jun 2008, 02:20
View user's profile Send private message Reply with quote
sleepsleep



Joined: 05 Oct 2006
Posts: 8975
Location: ˛                             ⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣Posts: 334455
sleepsleep
thanks for the input,
for further reading, reffer http://www.debian-administration.org/articles/388
Post 06 Jun 2008, 01:52
View user's profile Send private message Reply with quote
gunblade



Joined: 19 Feb 2004
Posts: 209
gunblade
Using XFS at the moment on all my drives, works great.

Its actually an interesting implementation of a filesystem, has really nice features, worth reading the source if your interested in that kind of thing.
Post 06 Jun 2008, 12:13
View user's profile Send private message Reply with quote
DOS386



Joined: 08 Dec 2006
Posts: 1901
DOS386
> which one asm programmer use? and any notable reasons

> which means NTFS currently.

Do you or anyone else have FASM code for NTFS handling ? If not, it has to be considered as pretty disqualified, hasn't ? Laughing

> But the FATs are not journalling so you have a higher risk of data loss.

Evidence please (YES, I've seen this statement already 1'000'000'000'000 times before) Wink

> ntsc3g has really made FAT32 useless

COOL ... but don't forget that NTFS is still possessed by M$ and there is still no official documentation about it ...

> reffer http://www.debian-adm

No debian-asm Laughing

(see shot below) FAT32 really doesn't look great here ... maybe they did test wrongly Confused ... FAT has design faults but I'm still using it ... no alternatives, brew my own ?

BTW, anyone has docs (not 1'000'000'000 lines of GCC code) on the "winner" Reiser 4 ?


Description: 1.94 KiB - 1`991 Bytes
Filesize: 1.94 KB
Viewed: 6237 Time(s)

loonix-fs.png



_________________
Bug Nr.: 12345

Title: Hello World program compiles to 100 KB !!!

Status: Closed: NOT a Bug
Post 08 Jun 2008, 23:55
View user's profile Send private message Reply with quote
edfed



Joined: 20 Feb 2006
Posts: 4240
Location: 2018
edfed
the file system i use:
FAT32

the file system i want:
FOOL

the difference:
modularity and transparency.
Post 09 Jun 2008, 00:54
View user's profile Send private message Visit poster's website Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17350
Location: In your JS exploiting you and your system
revolution
DOS386 wrote:
> But the FATs are not journalling so you have a higher risk of data loss.

Evidence please
I hardly think it is necessary to supply evidence. It should be obvious from the an understanding of the setup. But for anecdotal evidence I submit my experience. With FAT16, on my old DOS system, I had many occasions with lost clusters that needed recovery after a crash. With NTFS on my current systems, I have not ever lost any data no matter how badly the machine may have crashed.

Also your comparison charts seems to be weighted towards access time and disk usage. This assumes a lot about the requirements of the user. For my use my requirement is firstly reliability and secondary are all other measurements.
Post 09 Jun 2008, 05:35
View user's profile Send private message Visit poster's website Reply with quote
DOS386



Joined: 08 Dec 2006
Posts: 1901
DOS386
> I hardly think it is necessary to supply evidence.
> It should be obvious from the an understanding

Neutral

> many occasions with lost clusters that needed
> recovery after a crash. With NTFS on my current systems, I

OK ... I occasionally get lost clusters also
but it's not really a big problem ...

> Also your comparison charts seems to be weighted towards access time and disk usage. This assumes a

It's not mine ... it's picked from the "debian"
link ... I don't have debian (plus, considering
the 20 GiB+ distros, does filesystem efficiency
still matter then ??? Laughing
Post 09 Jun 2008, 09:27
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17350
Location: In your JS exploiting you and your system
revolution
DOS386 wrote:
OK ... I occasionally get lost clusters also
but it's not really a big problem ...
Much better to have no problems.
Post 09 Jun 2008, 10:02
View user's profile Send private message Visit poster's website Reply with quote
Octavio



Joined: 21 Jun 2003
Posts: 366
Location: Spain
Octavio
I use Fat but i will use Octafs (in development) in the future Smile
I see a lot of test where Fat performs worse that ext2 but from my own experience ext2 is slower and wastes more space,perhaps the problem is not the filesystem design itself but the driver implementation.
Post 09 Jun 2008, 10:24
View user's profile Send private message Visit poster's website Reply with quote
r22



Joined: 27 Dec 2004
Posts: 805
r22
Once Solid State Drives become mainstream the whole concept of FS will change significantly. No more platters and taking into account seek time and spin lag. File Systems should evolve err DEvolve to a simple streamlined design letting disk configurations like RAID 1/5/10 take care of redundancy and error correction.
Post 09 Jun 2008, 20:23
View user's profile Send private message AIM Address Yahoo Messenger Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17350
Location: In your JS exploiting you and your system
revolution
I don't see how SSD will change the FS landscape. RAID is still applicable no matter what the underlying drive technology is.

Remember that SSDs are not a general replacement for magnetic disks. They store data for a limited time (~10years) and have a limit on the number of writes (~100k writes). In short they wear out with use and they degrade with time.
Post 09 Jun 2008, 20:31
View user's profile Send private message Visit poster's website Reply with quote
edfed



Joined: 20 Feb 2006
Posts: 4240
Location: 2018
edfed
one of the best way to store datas will be Static RAM.

and an aditional energy system, able to catch it from various sources like wind?? sun, movments, electromagnetic pollution (radio and tv), sound, powersupply, etc etc...

the real memory would take like 10% of the available place in the module, the 90 other % will be used for the energy mechanism.

who thinks it is a good way to future?
Post 09 Jun 2008, 21:04
View user's profile Send private message Visit poster's website Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17350
Location: In your JS exploiting you and your system
revolution
edfed wrote:
one of the best way to store datas will be Static RAM.

and an aditional energy system, able to catch it from various sources like wind?? sun, movments, electromagnetic pollution (radio and tv), sound, powersupply, etc etc...

the real memory would take like 10% of the available place in the module, the 90 other % will be used for the energy mechanism.

who thinks it is a good way to future?
Nope, not a good system. Too risky, if the power circuitry fails for any reason then all your data is lost.

I remember reading a study about data storage over long term periods. The somewhat paradoxical conclusion was that almost all re-writeable/non-volatile (like HDD, or CDRW) were the best, and the others like CDR and paper were the worst. They looked at many different things like lack of electricity, atmospheric corrosion, fire, flood, vibration, temperature, etc. and still the humble old HDD was a very good option.
Post 09 Jun 2008, 21:28
View user's profile Send private message Visit poster's website Reply with quote
edfed



Joined: 20 Feb 2006
Posts: 4240
Location: 2018
edfed
yep, sure the HDD is not dead, but for evolution reason, main stream would use more and more Static Ram for local storage, global storage using the GOOD OLD HDD.

like in PC there are many cache levels, adding one more stage will not be a problem at all.

NETWORK > HDD > SRAM > DDR > L2 > L1 > REGISTERS > SOFT(HARD)WARE

why software as the last layer? because datas are nothing without soft and hardware to interpret them.
Post 09 Jun 2008, 21:57
View user's profile Send private message Visit poster's website Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17350
Location: In your JS exploiting you and your system
revolution
edfed: Why the fascination with SRAM? SDRAM is faster, larger storage capacity, and cheaper. Both require power to keep data. SRAM need 6 transistors per bit vs SDRAM with 1 transistor per bit.
Post 09 Jun 2008, 22:15
View user's profile Send private message Visit poster's website Reply with quote
edfed



Joined: 20 Feb 2006
Posts: 4240
Location: 2018
edfed
SRAM because i don't know what is exactlly SDRAM.

SRAM because it can be made not only with Transistors.

SRAM because i didn't think about SDRAM

and one error from you, one bit in sram use only two transistors, two capacitors and four resistors.

after, it depends on what you use for the realisation, mos or bipolar?
in case of mos, no need of capacitors and divide by two the number of resistors.

and SDRAM need a periodic refresh
Post 09 Jun 2008, 22:56
View user's profile Send private message Visit poster's website Reply with quote
DOS386



Joined: 08 Dec 2006
Posts: 1901
DOS386
> Much better to have no problems.

True, but also much better to have specs + have FASM code to deal with your FS ...

Octavio wrote:

> I use Fat but i will use Octafs (in development) in the future

License ? Do you intend to keep it proprietary / exclusive for OctaOS or make it available also for DOS for example ? Drafts ? I indeed also develop ideas for a new FS for DOS ...

> own experience ext2 is slower and wastes more space,perhaps the problem is not the filesystem design itself but the driver implementation.

Very true ... old known trick ... M$ crippled FAT32 to 4 GiB file size + 32 GiB volume size just to promote NTSC this way Sad
Post 09 Jun 2008, 23:14
View user's profile Send private message Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  
Goto page 1, 2, 3  Next

< Last Thread | Next Thread >
Forum Rules:
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You can attach files in this forum
You can download files in this forum


Copyright © 1999-2020, Tomasz Grysztar. Also on YouTube, Twitter.

Website powered by rwasa.