August 1, 201015 yr Simple request for ext3 support in unRAID. For me it would be invaluable for mounting USB HDDs for data in and out. We know that under some conditions you can mount ext3 using ext2 but not all. Please feel free to vote; I only added it for fun. Please don't vote with "yes but i want something else first or blah is more important than this" in mind... importance is for Limetech to decide
August 1, 201015 yr Author Seems people voting doesn't bump the thread to "new replies status". thanks to those that voted so far. TBH i dont expect a landslide either way just curious what kind of vote count we will get
August 2, 201015 yr Author Yeah I agree. personally i think unRAID should do the exact opposite of what it does this now namely instead of supporting as few as possible fs it should support the most I suppose this is as good a place as any to disucss. Debian stable nodev sysfs nodev rootfs nodev bdev nodev proc nodev cgroup nodev cpuset nodev debugfs nodev securityfs nodev sockfs nodev usbfs nodev pipefs nodev anon_inodefs nodev tmpfs nodev inotifyfs nodev devpts nodev ramfs nodev hugetlbfs nodev mqueue ext3 nodev fuse fuseblk nodev fusectl nodev rpc_pipefs nodev nfsd Ubuntu server nodev sysfs nodev rootfs nodev bdev nodev proc nodev cgroup nodev cpuset nodev tmpfs nodev devtmpfs nodev debugfs nodev securityfs nodev sockfs nodev pipefs nodev anon_inodefs nodev inotifyfs nodev devpts ext3 ext2 ext4 nodev ramfs nodev hugetlbfs nodev ecryptfs nodev fuse fuseblk nodev fusectl nodev mqueue nodev vmhgfs nodev cifs unRAID nodev sysfs nodev rootfs nodev bdev nodev proc nodev tmpfs nodev sockfs nodev usbfs nodev pipefs nodev anon_inodefs nodev rpc_pipefs nodev inotifyfs nodev devpts reiserfs ext2 nodev ramfs vfat msdos iso9660 nodev nfs nodev nfsd nodev cifs nodev fuse fuseblk nodev fusectl
August 2, 201015 yr There seem to be allot listed that will not be used by unRAID, and it seems unRAID has a few the others do not. I think we just need to have ext3 & ext4 added. What others do you think people will need?
August 2, 201015 yr Author Yeah sorry these were copy and pastes of default installs not a suggestion on what should be included. My focus would be to make it easy for users to pop a dive into unRAID via USB and fill or empty it. So saying this the filesystems we need are the ones people use. That obviously is impossible to answer so i would suggest picking the top 10 OSs and seeing what they use as default. I suspect the list will boil down to ext2 ext3 ext4 reiser NTFS (proper support) fat fat32
August 2, 201015 yr Yeah sorry these were copy and pastes of default installs not a suggestion on what should be included. My focus would be to make it easy for users to pop a dive into unRAID via USB and fill or empty it. So saying this the filesystems we need are the ones people use. That obviously is impossible to answer so i would suggest picking the top 10 OSs and seeing what they use as default. I suspect the list will boil down to ext2 ext3 ext4 reiser NTFS (proper support) fat fat32 Don't forget the MAC specific file-system HFS. (Its driver is already in unRAID)
August 2, 201015 yr Author Slightly off topic but can you tell Linux to do something based on a specific USB port. What i am thinking is eventually "if you see a FS on this PORT then move all the data to here". In a similar vain to if you see a CD then make it an iso and save it here.
August 2, 201015 yr Slightly off topic but can you tell Linux to do something based on a specific USB port. What i am thinking is eventually "if you see a FS on this PORT then move all the data to here". In a similar vain to if you see a CD then make it an iso and save it here. Take a look at S.N.A.P
August 2, 201015 yr I could have saved about 3 days work recently if unRAID supported xfs. But, at least ext2 and ext3 should be supported IMO.
August 2, 201015 yr Slightly off topic but can you tell Linux to do something based on a specific USB port. What i am thinking is eventually "if you see a FS on this PORT then move all the data to here". In a similar vain to if you see a CD then make it an iso and save it here. This is what I loved about my ReadyNAS. Put a USB key into a specific port and it was copied to a dated directory YY-MM-DD HHMMSS it was great for downloading camera pics.
November 1, 201015 yr Author Now that Limetech are talking about new versions I wanted to bump this thread. Everyone wants something but for me ext3/4 would save me no end of farting about. NTFS would be great too but ext3 would allow me to use SNAP
November 1, 201015 yr Now that Limetech are talking about new versions I wanted to bump this thread. Everyone wants something but for me ext3/4 would save me no end of farting about. NTFS would be great too but ext3 would allow me to use SNAP I thought it was already available in the kernel, which should allow you to use SNAP.
November 1, 201015 yr Now that Limetech are talking about new versions I wanted to bump this thread. Everyone wants something but for me ext3/4 would save me no end of farting about. NTFS would be great too but ext3 would allow me to use SNAP I thought it was already available in the kernel, which should allow you to use SNAP. ext2 is, but probably not ext3.
November 1, 201015 yr If ext4 were available, then we would have trim support for SSD's as a cache drive.
November 1, 201015 yr Author Yeah there are lots of uses for having more fs supported. Hopefully just adding the support to the kernel should be easy with no ramifications/extra work to unRAID in general. Would make my life much simpler so I am biased as to wanting this
November 1, 201015 yr One of the main reasons I run my prod box on a full Slack distro is for the extra filesystem support. I would also be in favor of more filesystems supported natively -- ext2/3/4 in particular. I can live with some of the odd ones left out and I can use a dev box to get to them on the rare occasion that is necessary. Of course, then initramfs bloat raises its head ... and the idea of an overlay fs still is on my "good idea" list.
November 2, 201015 yr Does not sound like a huge advantage to the Windows-based user. Slower and lesser undelete functionality? Am I missing something? http://en.wikipedia.org/wiki/Ext3
November 2, 201015 yr Author They don't have to use it if they don't want to. Windows user can stick to fat32 or perhaps ntfs-3g can be added to.
November 7, 201015 yr Recently I read an article about robust file systems, and it generally viewed that it takes at least 5 years to iron many of the bugs, this is after the release date, so personally, I'm not trusting ext4 just yet, however, I do use it one my laptop. I biased towards data integrity over out and out I/O performance...I voted for ext3...it is a very stable file system, and has good recovery tools,
November 7, 201015 yr NAS, perhaps you should clarify... adding ext3 just means the ability to mount an ext3 drive under unRAID outside the array, not to use ext3 natively as the underlying filesystem on array disks.
November 7, 201015 yr Have to admit, until I read this I assumed you would be able to mount an ext3 file system Its such a 'standard' in the *nix world. Having choice for the underlying array files system would also be nice, XFS is great with large files, so I'm intrigue why ReiserFS was chosen for a media biased server...but that is another thread for another post someday. This post goes some ways to explaining the choice for the underlying file system for unRAID. http://lime-technology.com/forum/index.php?topic=283.0
November 7, 201015 yr perhaps ntfs-3g can be added to. I second this. I'm not one of them but I think having ntfs-3g in unraid would be usefull to a lot of people. For those who don't know, this module allows full read and write to ntfs partitions. All portable hard drives you buy come formatted as ntfs so for those who would like to connect a drive to unraid and make secondary backups for off-site storage or whatever it would be very nice. I voted yes for ext3 (ext4 too please). I think it should include many of these somewhat popular filesystems.
Archived
This topic is now archived and is closed to further replies.