Why ext4 partition android

As a side note, sda1 is just a small 1GB partition. I will assume that your device is rooted from what you have done so far so will not go into that. Though I cannot be certain this is your issue I shall explain how I solved a similar problem. Resent versions of android with the intent on improving device security are now using the somewhat half arsed feature of making mounts performed by most processes not visible to other processes.

Working around this is frustratingly device specific, however it appears the Minix NEO X8-H is using a "vanilla" style source build of android. Therefore you have a good chance of using StickMount in order to mount the USB stick, it should enable the global mounting of USB devices running any file-system supported by your ROM which should include ext4 given you have already mounted it before.

I have not tested this personally on your device so cannot guarantee it will work but have had success with a number of other android devices so this is certainly worth a shot. Stack Overflow for Teams — Collaborate and share knowledge with a private group.

Create a free Team What is Teams? Collectives on Stack Overflow. Learn more. How to mount an external drive's ext4 partition on android and make it rw-available to all the apps Ask Question.

Asked 6 years, 7 months ago. Active 4 years, 3 months ago. Viewed 16k times. Improve this question. Both of them have no realistic file-size or partition-size limits. The latest smartphones support exFAT file system.

These differences on a desktop will probably not be visible to you, especially if you already have a fast disk. Until , Linux distros relied on the kernel ntfs driver which was read-only. Various benchmarks have concluded that the actual ext4 file system can perform a variety of read-write operations faster than an NTFS partition. For example, ext4 supports delayed allocation directly. Although a complete change to the new ReFS file system was rumored by professionals in recent months, the last technical build released by Microsoft resulted in no dramatic changes and Windows 10 continuing to use NTFS as the standard file system.

Skip to content Android Windows Linux Apple. Home » Android. Try more general keywords. Try fewer keywords. This is topical with the thread above about filesystem behaviour. Once people are using something, it's too late to decide how they should use it. So Google optimise for the former, not the latter, trusting that a nerds will find the way to do whatever they need to do even if you don't make it obvious, so there's no need b the nerds don't read adverts and thus don't generate any significant revenue.

As with XKCD's imaginary secret tech support password, it would be nice if Google provided a raw search facility for people who can spell, know what they're looking for and understand what "not found" means, but it doesn't necessarily make commercial sense.

If you ask users "Are you an expert? And then they complain that they don't understand what happened next. If you provide a "secret" expert mode, "helpful" journalists tell ordinary users about it, and you're back to the same situation.

I bet that fully half the quoted search queries on Google are users who don't know what quotes do, but believe that it somehow makes the search give more results, or better results.

Prefixing with plus turns off correction with the Bing, which quite politely doesn't offer some obnoxious correction even after explicitly being told not to. As an aside, Bing's fancy augmented search results page is much less annoying than Google's, even though it still has behaviour that triggers on mouse-over. Motorola Droid for user multimedia data etc. The trend seems to be going towards fitting phones with a large SD card-like flash chip Google nexus S , which requires no external wear levelling and thus is suited to conventional filesystems like ext2,3,4 etc.

The idea of a "flash filesystem" that's built for low-performance applications is one I'm happy to see die. One of the big advantages of flash storage is the potential for parallel operations. I think moving to full-featured filesystems, potentially with tweaks to be friendly to solid state storage, will produce a much better overall result than you'd get by starting with a software FTL and then trying to grow a specialized filesystem on top.

The upside is you get something that behaves like a block device, and you can use plain 'ol filesystems on with little or no special handling. I don't know anyone who removes batteries from his or her phone "all the time. Second of all, you'd have to know how to get at the battery. This is already beyond the skill level of grandma-type users. Keep in mind that some phones don't even have a removable battery, like the iPhone. Thirdly, you have to be dumb enough to not know the normal way of turning off the phone.

Do all three of these factors really line up that often? I'm skeptical. I think once and then having the FS corrupt would be enough to piss off most people, will cause upset feelings and costs on both the customer service and customer side of things. I couldn't imagine recovering from a non-functioning firmware would be fun for most people.

Probably would require mailing the thing in or a drive to the service center. It is not like you can just plug in your Ubuntu CD and go into recovery mode or anything like that.

The only wildcard is the behavior of the flash firmware. If it lies to you and says things are committed to flash when they really aren't, really anything could happen. However, it's hard to see how any filesystem can get around this problem, if it exists. Keep in mind you can't rely on ordering either, since the flash firmware needs to reorder your requests to do wear leveling and so forth. User: Password:. Ext4 filesystem hits Android, no need to fear data loss ars technica [Posted December 27, by ris].

Ext4 filesystem hits Android, no need to fear data loss ars technica Posted Dec 28, UTC Tue by mikov guest, [ Link ] I posted this question on Ars, but I think I have a better chance of getting a good answer here: Doesn't Ext4 rely on a generic block layer?

Ext4 filesystem hits Android, no need to fear data loss ars technica Posted Dec 28, UTC Tue by rich0 guest, [ Link ] I suspect that wearing out the flash earlier so that you have to buy a new phone is considered a feature, not a bug.

These are the guys who stop releasing security patches for phones that contain web browsers less than a year after they have been sold to people with 2-year contracts. The problem is that fsync is a much slower, more heavyweight operation than is actually needed in most cases.

Usually what you need on recovery is consistency, not durability. Rename-replace points are an unusually convenient place to provide consistency. The FS just needs to go a little out of its way to make sure that upon recovery after a rename replace you either get the old version or the new version of the file being replaced To be sure, the quick and dirty way of providing consistent rename replace is for the FS to force the new version to permanent storage before committing the rename transaction.

That is not really necessary though. You can also create rename undo records and on recovery roll back to the last completely written version. No sync serialization required, let alone the user visible thumb twiddling variety. Ext4 filesystem hits Android, no need to fear data loss ars technica Posted Dec 28, UTC Tue by mjg59 subscriber, [ Link ] "Unrelated files will not be corrupted or lost if fsync is not used" That's true, but the fact that it's POSIXly ok to transform the "Write to temporary file, rename over original" sequence into "rename over original, then commit new data to disk" means that the definition of "unrelated" is not always what application developers expect.

Ext4 filesystem hits Android, no need to fear data loss ars technica Posted Dec 28, UTC Tue by iabervon subscriber, [ Link ] POSIX doesn't make any guarantees at all about what happens when the system stops and starts again, so it would be hard for Linux to be useful and not make stronger guarantees.

Or, rather, Linux filesystems don't guarantee anything more the reason your system crashes could conceivably be that your video driver has started sending data to your hard drive instead of your video card, entirely wiping out your storage , but the behavior that Linux rarely diverges from is substantially better than POSIX requires. Ext4 filesystem hits Android, no need to fear data loss ars technica Posted Dec 28, UTC Tue by Trelane subscriber, [ Link ] So it sounds like fsync would work except that it flushes data and metadata, thereby causing performance issues, yes?

If so, a nice solution may be to introduce a metadata-only sync? And the second part of that plan is to use threads and internal queues to achieve the same overall effect; that's not really an option for userspace. I was citing his report on a meeting of several filesystem developers. He wasn't say what "should". He was saying what "is". Ext4 filesystem hits Android, no need to fear data loss ars technica Posted Dec 29, UTC Wed by iabervon subscriber, [ Link ] The thing is that transactional rename semantics works for all POSIX-compliant filesystems when your computer doesn't crash.

Anything that's only needed if your computer crashes isn't going to be used consistently, because developers' computers crash so rarely and it's awkward to include in an application regression test suite. Ext4 filesystem hits Android, no need to fear data loss ars technica Posted Dec 29, UTC Wed by neilbrown subscriber, [ Link ] fsync is only needed if your computer crashes. Not using it works perfectly when your computer doesn't crash. Syncing has significant performance penalties.

Posted Dec 29, UTC Wed by gmatht guest, [ Link ] The applications that actually really need durability of data written in the last few seconds don't seem to be that common Ext4 filesystem hits Android, no need to fear data loss ars technica Posted Dec 29, UTC Wed by iabervon subscriber, [ Link ] Using fsync only really makes sense if you're trying to get stuff written to disk before sending a message out of the system; otherwise, it won't be possible to tell whether the fsync didn't actually do anything or the system crashed before it returned.

So you need to use fsync after writing a received email message to disk and before telling the remote server that you've got it. Ext4 filesystem hits Android, no need to fear data loss ars technica Posted Dec 30, UTC Thu by iabervon subscriber, [ Link ] My model can't really fail to be accurate, since it includes the possibility of arbitrary deviations from the predicted outcome. And, actually, nothing is safe at all; your storage medium might fail, your video driver might scribble over your disk or your dirty pages, your hard drive might read garbage out of memory losing power and write it with the power left in its capacitors.

I actually suspect that, based on the model I stated, a more common and more extensive source of differences from some potential snapshot is things that syncing couldn't have helped with than things that syncing could have helped with with the exception of ext4 having a particularly common and obvious divergence. User specified dependencies are completely unnecessary.

All that is necessary is for filesystems to exercise a little bit of additional effort to preserve POSIX semantics across system crashes.

That means atomic renames, among other things. Very simple: log the rename in the journal. Keep the old inode around until the data associated with the replacement inode commits to disk. If the system crashes in the meantime, on recovery undo the rename, thereby restoring the association between the name and the old inode. No need to commit the new inode data implicitly or explicitly prior to writing any metadata journal entries. No need to call fsync unless you actually want synchronous behavior.

No need to start writeout on the new inode immediately, either. That can lead to severe performance issues, unless you implement some sort of multiversion concurrency a la BSD style "soft updates" on all your metadata.

There are better ways. Durability once written stay written is a different requirement, but in this particular instance we need atomicity: do the rename in one step, so it's either finished or not done. The same goes for appending to an existing file: either append or do not append, but at no point in the process leave a corrupt file. It's ironic that the outcome of optimising certain performance characteristics of a filesystem would have required userspace to behave in a way that's almost precisely pathological on the previous generation of the same filesystem, but the rational approach to this is "Optimise filesystems for the way that real-world applications work" not "Optimise filesystems for a benchmark".

POSIX doesn't provide a mechanism for atomicity without durability, so if application developers want one without the other then they're going to have to rely on implementation details. Filesystems that don't understand that are doomed to irrelevance. I'm not quite sure if developers know what they want, most of the time. At least, there seem to be a lot of misconceptions and misuse of these things. I don't think SQL provides atomicity without durability, does it?

But in those instances it is safe and clean to provide it by using fsync. I don't care if my application pauses for a few seconds after saving a file to disk, but at that point I want durability.

I don't want it to stop every minute when it saves an emergency backup file, but neither do I want it to corrupt said emergency file; at those moments I want atomicity.

I still fail to see what is missing here. You just want your renames to be atomic: either keep the old file or overwrite it with the new one. And the same with appends. It's not really important which version old or new is left on disk, but do never leave corrupted files empty files or files with unitialized sectors. Not an empty file, but either the old version or the new. Not again Posted Dec 31, UTC Fri by etienne guest, [ Link ] How about, when you want to save the new configuration file, not trying to replace the old config file - just keep it in case the new config file is incomplete, still not created or corrupted after crash?

Should work with any filesystem. Would you keep all the old files? You can also keep two of them, but how do you know which one of them was the last one written? What if one of them is half-written? That way leads to madness.