flat assembler
Message board for the users of flat assembler.

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

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



Joined: 08 Feb 2005
Posts: 1601
Location: web
Dex4u
DOS386 wrote:
> 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


Sure i have fasm code for NTFS read, even works from Dos.
Post 10 Jun 2008, 00:14
View user's profile Send private message Reply with quote
f0dder



Joined: 19 Feb 2004
Posts: 3170
Location: Denmark
f0dder
revolution wrote:
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.
Amount of write cycles depend on the flash type and the wear-levelling algorithm. ~10 years? Show me a (recent, high-capacity) harddrive that'll survive 3+ years of sustained use Smile

As for filesystems, for practical use, NTFS for my windows boxes... I've had enough crash problems with FAT that I won't consider that filesystem for anything but relatively unimportant data transfers, or ease-of-boot for homebrew OSes.

Especially since ntfs3g seems mature now, there's not even the concern about "but what will I do with my data if I can no longer use windows". Yeah yeah, evil megacorp Microsoft controls NTFS and it's not open-spec, etc. yadda yadda, but it's the best choice if you run Windows.

For linux, EXT3 and XFS. ReiserFS has some nice properties when you deal with lots of small files (like Maildir), but now it seems even more evident that ReiserFS is THE killer filesystem, which makes me vary of using it - too bad.
Post 10 Jun 2008, 01:58
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: 17278
Location: In your JS exploiting you and your system
revolution
edfed wrote:
SRAM because i don't know what is exactlly SDRAM.
Haha, that is not a good reason.
edfed wrote:
SRAM because it can be made not only with Transistors.
It is 100% transistors.
edfed wrote:
SRAM because i didn't think about SDRAM
Another bad reason there.
edfed wrote:
and one error from you, one bit in sram use only two transistors, two capacitors and four resistors.
Okay, but what era of technology are you thinking of? Modern SRAMs use the standard 6T design, no resistors in CMOS.
edfed wrote:
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.
There are no companies making SRAM with BJT technology that I know of. BJT would be very very inefficient.
edfed wrote:
and SDRAM need a periodic refresh
Yes it does, but with modern SDRAMs they have internal counters and during system standby it is an easy matter to put it into self refresh. That is how the laptops implement standby mode.
Post 10 Jun 2008, 02:56
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: 17278
Location: In your JS exploiting you and your system
revolution
f0dder wrote:
Amount of write cycles depend on the flash type and the wear-levelling algorithm. ~10 years? Show me a (recent, high-capacity) harddrive that'll survive 3+ years of sustained use Smile
Well I can show you many drives around here that are still working happily after 7 years in a RAID server. Or perhaps you are being facetious since a "recent high-capacity drive" might, by definition, be less than 3 years old, hard to tell what the smiley is supposed to indicate.

I expect that the normal SSDs will use the much cheaper 100k write flash chips. The market would have a hard time selling SSDs with the more expensive 1M chips. Remember it is just flash ROM, nothing more. 10 years data retention is normal, some companies claim 40 years but those chips cost more (of course).

An SSD with continuous use will have the same problem as the HDD, they both wear out, but in different ways. So it would depend upon your storage requirements in that case.
Post 10 Jun 2008, 03:27
View user's profile Send private message Visit poster's website Reply with quote
bitRAKE



Joined: 21 Jul 2003
Posts: 2915
Location: [RSP+8*5]
bitRAKE
For a read only drive (reference material / library) the Flash drive would last much longer than any drive with a motor.

_________________
¯\(°_o)/¯ unlicense.org
Post 10 Jun 2008, 03:52
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: 17278
Location: In your JS exploiting you and your system
revolution
bitRAKE wrote:
For a read only drive (reference material / library) the Flash drive would last much longer than any drive with a motor.
Up to the 10 year retention lifetime that would probably be correct. But if you are reading infrequently (say a few times per month) then I think an HDD would be the better option for long term storage.
Post 10 Jun 2008, 04:04
View user's profile Send private message Visit poster's website Reply with quote
f0dder



Joined: 19 Feb 2004
Posts: 3170
Location: Denmark
f0dder
revolution wrote:
Well I can show you many drives around here that are still working happily after 7 years in a RAID server. Or perhaps you are being facetious since a "recent high-capacity drive" might, by definition, be less than 3 years old, hard to tell what the smiley is supposed to indicate.
Wasn't meant to be a trick, just that "pretty old" drives (like my own very first harddrive, ~500meg) seemed to be very sturdy... but more recent drives, at least the consumer-grade ones, seem flimsy. I've learned not to trust anything that isn't in a raid mirror and has a 80mm or 120mm intake fan right in front of it.

I'm not suggesting that SSDs should take over the world and replace harddrives, by the way - at least not yet. Capacities are still too small, they're too expensive, and most of them still seem to have issues with "many small writes" (solvable by adding some larger RAM buffers and more circuitry?). But it would be pretty darn nice as system+apps drive, with bulk storage on a local gigabit fileserver.

revolution wrote:
An SSD with continuous use will have the same problem as the HDD, they both wear out, but in different ways. So it would depend upon your storage requirements in that case.
Once a SSD wears out, isn't it just individual blocks that can no longer be erased? Or do you lose the contents of the blocks as well? Even if you lose the contents of the block, it would still be preferable to a full head crash on a harddrive, imho Smile
Post 10 Jun 2008, 12:31
View user's profile Send private message Visit poster's website Reply with quote
Borsuc



Joined: 29 Dec 2005
Posts: 2466
Location: Bucharest, Romania
Borsuc
f0dder wrote:
Amount of write cycles depend on the flash type and the wear-levelling algorithm. ~10 years? Show me a (recent, high-capacity) harddrive that'll survive 3+ years of sustained use Smile
Haha, flash have 'old-harddisk' capacities, so you'd better compare to those Wink

I like NTFS because of compression (In my logic (i don't know) that means fewer hard-disk reads and more CPU usage, which is fine by me).

any articles on data journalling? or whatever it's called, I never understood what it is though
Post 10 Jun 2008, 13:02
View user's profile Send private message Reply with quote
f0dder



Joined: 19 Feb 2004
Posts: 3170
Location: Denmark
f0dder
The_Grey_Beast: high-capacity drives are what you buy today, though... but hell, I'll even consider an 80gig drive "high capacity", compared to my old 512meg drive Wink

NTFS compression is interesting and all, but you should use it mostly for static (read-only) data, as it can cause fragmentation on writes. And remember never to compress NTLDR, boot.ini, ntdetect.com Smile

Data journalling... well, NTFS has "metadata" journalling - this means that generally your filesystem shouldn't get corrupted, but that individual data blocks in a file might be. Newer systems like ZFS (and iirc, also ext3 (optionally)) can do data-block journalling as well - which means that on write, the block with new data won't be used (and updated in the fs metadata) until it's fully flushed to disk. Still, you can end up with corrupted files.

Here's the wikipedia article on Journaling file system.

With Windows Vista, a new set of APIs have been added: transactional NTFS. Seems pretty interesting, as you get some control yourself over the transactions, basically giving you the ability to do "all-or-nothing" filesystem updates...
Post 10 Jun 2008, 13:20
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: 17278
Location: In your JS exploiting you and your system
revolution
f0dder wrote:
Once a SSD wears out, isn't it just individual blocks that can no longer be erased? Or do you lose the contents of the blocks as well? Even if you lose the contents of the block, it would still be preferable to a full head crash on a harddrive, imho Smile
There are two mechanisms that are at work with SSDs

1) the write limitation, I think we all know that one.

2) the storage lifetime; with the progress of time the little floating gate inside each flash cell leaks electrons, this limits the long term storage integrity. Typical figures given by manufacturers give ~10 years retention. This happens regardless of whether you are actively reading the device or if it is not powered. It is chip-wide, not just individual blocks, and all cells suffer then same. Indeed it is guaranteed that given enough time all cells will lose their stored charge. Methods to mitigate the problem are to erase and rewrite periodically to refresh the stored charge, which brings us back to problem 1 above.
Post 10 Jun 2008, 13:31
View user's profile Send private message Visit poster's website Reply with quote
Borsuc



Joined: 29 Dec 2005
Posts: 2466
Location: Bucharest, Romania
Borsuc
f0dder wrote:
NTFS compression is interesting and all, but you should use it mostly for static (read-only) data, as it can cause fragmentation on writes.
Obviously I use it only on data that is read, I'm not that stupid, but then I defrag every week, it takes mostly a minute or two, no prob.

f0dder wrote:
And remember never to compress NTLDR, boot.ini, ntdetect.com Smile
sorry for being a windows-noob but why?

(not that I did compress them anyway, but I'd like to know)

f0dder wrote:
Data journalling... well, NTFS has "metadata" journalling - this means that generally your filesystem shouldn't get corrupted, but that individual data blocks in a file might be. Newer systems like ZFS (and iirc, also ext3 (optionally)) can do data-block journalling as well - which means that on write, the block with new data won't be used (and updated in the fs metadata) until it's fully flushed to disk. Still, you can end up with corrupted files.

Here's the wikipedia article on Journaling file system.

With Windows Vista, a new set of APIs have been added: transactional NTFS. Seems pretty interesting, as you get some control yourself over the transactions, basically giving you the ability to do "all-or-nothing" filesystem updates...
Thanks
Post 10 Jun 2008, 13:53
View user's profile Send private message Reply with quote
f0dder



Joined: 19 Feb 2004
Posts: 3170
Location: Denmark
f0dder
The_Grey_Beast wrote:
Obviously I use it only on data that is read, I'm not that stupid, but then I defrag every week, it takes mostly a minute or two, no prob.
Not saying you're stupid, but some people don't seem to know this... then again, some people also use NTFS compression on MP3 files ^_^

The_Grey_Beast wrote:
f0dder wrote:
And remember never to compress NTLDR, boot.ini, ntdetect.com Very Happy
sorry for being a windows-noob but why?

(not that I did compress them anyway, but I'd like to know)
During initial phases of boot, a very simplified NTFS driver is used, which basically is read-only, only handles root directory, and certainly doesn't have compression/encryption support. So you need to keep those core files non-encrypted and non-compressed.
Post 10 Jun 2008, 13:58
View user's profile Send private message Visit poster's website Reply with quote
bitRAKE



Joined: 21 Jul 2003
Posts: 2915
Location: [RSP+8*5]
bitRAKE

_________________
¯\(°_o)/¯ unlicense.org
Post 10 Jun 2008, 14:06
View user's profile Send private message Visit poster's website Reply with quote
f0dder



Joined: 19 Feb 2004
Posts: 3170
Location: Denmark
f0dder
bitRAKE: holy moley, 20 pages for that SD(HC) article? And long pages? I think I'll skip for now Smile - when speaking about SSD, it's usually stuff like this people are talking about though, not flash cards.
Post 10 Jun 2008, 14:14
View user's profile Send private message Visit poster's website Reply with quote
Octavio



Joined: 21 Jun 2003
Posts: 366
Location: Spain
Octavio
DOS386 wrote:
> 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

Octafs license is the same as for OctaOS or Octasm: public domain.
I will not port it to other Oses but somebody else can do it.
There is no Draft yet i design and write the code at the same time,but i will put a article on my web explaining it.
The main idea of this filesystem is to allow file edition ,like deleting just a byte at the begining of a big file without rewriting the entire file ,this feature was planed on reiserfs too but ...
Also my fs can store a lot of small files without wasting space.
The filesystem is also designed to be easily recoverable (some redundancy,some checksums,error isolation ...).
And since i´m a assembly programer i expect it to have better performance than other filesystems (seriously) Smile
Post 10 Jun 2008, 17:23
View user's profile Send private message Visit poster's website Reply with quote
bitRAKE



Joined: 21 Jul 2003
Posts: 2915
Location: [RSP+8*5]
bitRAKE
f0dder wrote:
bitRAKE: holy moley, 20 pages for that SD(HC) article? And long pages? I think I'll skip for now Smile - when speaking about SSD, it's usually stuff like this people are talking about though, not flash cards.
Yeah, that SD(HC) link is a speed database - not an article really. I'd rather have an SD card slot in a very thin notebook than some what-a-be harddrive. My laptop lets me boot off SD cards or USB flash - I don't need any other legacy interfaces, but 114MB/s would be nice verses the 35MB/s I get now. Surely it costs MUCH more than 3x my USB stick though. Smile I'll wait a couple years more...it wont take long for the new USB standard to be saturated with a Flash drive.

_________________
¯\(°_o)/¯ unlicense.org
Post 10 Jun 2008, 21:13
View user's profile Send private message Visit poster's website Reply with quote
f0dder



Joined: 19 Feb 2004
Posts: 3170
Location: Denmark
f0dder
SATA/PATA SSD has the advantage that it doesn't need special OS or BIOS support, though... and hopefully it'll have better hardware wear-leveling than your standard run-of-the-mill SD-card or USB pendrive.

I'm also going to wait a few years, though - I don't feel like paying the extreme premium that SSDs currently come at. Also, Intel+IBM (I think? as well as some others) are researching a new type of flash that's going to be faster and offer more write cycles - and cheaper to manufacture. Once that's out of R&D and into mass production, things might become interesting. Also, memristorssuond interesting, but that's probably "some years" in the future.

But in a few years, I hope to have a laptop with a decent SSD, and perhaps my OS+apps drive in my workstation as well. Would definitely do wonders for boot and launch times, harddrives don't really beat the random-seek properties of flash memory Smile

PS: perhaps a moderator could move the non-filesystem related posts to a new thread?
Post 10 Jun 2008, 22:25
View user's profile Send private message Visit poster's website Reply with quote
edfed



Joined: 20 Feb 2006
Posts: 4237
Location: 2018
edfed
a file (in a computer) is a random-size memory zone.
then, guiving this characteristic, we can conclude what is neede to access them:
a size and a location.

then, to remember the locations of all these files, we need a sort of tree interpreted as a metafile.

then, all is a file
a sector is a file.
a file is a string of sectors.
paging in µP and paging in HD are both possible.
then, the problem is not the file system but the code in assembly to access it the more friendly possible.

a very good question i have since a good time:


main entry
(size, path and location followed by all the structure)
__________________
on boot sector
or
on another sector?
__________________
as a sector location (LBA or CHS)
or
fixed somewhere in the drive, like 2 nd sector.
__________________
infinite size
or
fixed size, like 1, 4, 8 sectors

i prefer the all first choises but i meet some difficulty to code it.
Post 10 Jun 2008, 22:50
View user's profile Send private message Visit poster's website Reply with quote
f0dder



Joined: 19 Feb 2004
Posts: 3170
Location: Denmark
f0dder
The_Grey_Beast: you might be interested in this link from IBM about some of linux' journalling filesystems (found through OSNews).
Post 12 Jun 2008, 23:30
View user's profile Send private message Visit poster's website Reply with quote
Borsuc



Joined: 29 Dec 2005
Posts: 2466
Location: Bucharest, Romania
Borsuc
Thanks, I already knew about this technique, but I never thought it was called 'journalling' before Wink

(although I did not know that there were more than one type)
Post 13 Jun 2008, 14:07
View user's profile Send private message Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  
Goto page Previous  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.

Powered by rwasa.