Database Users

please close thread

Development has been integrated with the new rootfs.
Please see the thread here:
http://forum.xda-developers.com/showthread.php?t=584707
New version coming soon:
Version 2.3 info:
-Newer simplified setup, whether you use a partition or not you will use the same files;
- fixed copying issues that were stopping some Donut builds from working. All builds should now work file.
-there are no additional files unlike previous builds.
- support for a data partition as well.
- supports all phones that the rootfs is supporting, kaiser vogue diamond etc.
Version 2.2 info;
updated for better data file backup naming.
updated to support donut
updated to support wifi (thanks enate for this)
Version 2 info;
On boot it will prompt you to boot the new recovery image, if you press a key it will load the recovery image, (the first boot you must do this to install the system) if not it will boot as normal.
If you have a system.sqsh on your sd card it will prompt you to install to your ext2 partition
- after installing the system it will move it to /sdcard/installedsystem/installedsystem.sqsh
- it will move your data file to /sdcard/datafilebackup/data$date
and create a new one. After the inital boot you can reboot and copy back your data file again.
There is one caveat that was pointed out to me today. Do not change systems twice in one day unless you don't care about your data. Because it creates the data file based on date it will overwright the old one.
Why not data to? Well our current data.img solution is awesome for backing it up.
What's coming;
Native support for update.zip's from the dream themes forum.
Menu support with several different usefull options for setting up android (this is proving to be tough but I'm working on it)
here it is!
http://code.google.com/p/vogue-andr...name=recoverfiles2.2.rar&can=2&q=#makechanges

mssmison said:
Hey guys, I've got something new coming for vogue android, I need 2 people with VOGUES's only to test something for me.
Requirements; linux install, vogue only, be able to provide bug reports, be serious!
pm me; I'm hoping to have testing ready by the end of the day.
Click to expand...
Click to collapse
sure
have linux and vogue pmed you. dang, guess i didnt pm you in time...

I don't know what this is, but you've sure got me curious as hell.
If you need another tester, let me know.

Well looks like I'm not in the closed beta, but I'm looking forward to this with great excitement. With the loss of Zen, it's good to have you back and active on this stuff again. This wouldn't happen to be Android running natively on our little wonder-units would it?

stickus said:
Well looks like I'm not in the closed beta, but I'm looking forward to this with great excitement. With the loss of Zen, it's good to have you back and active on this stuff again. This wouldn't happen to be Android running natively on our little wonder-units would it?
Click to expand...
Click to collapse
Technically, Android doesnt run "native" on any device. You don't have to port a device to android..just the linux kernel to get api's to work. I know your refering to booting android on our faster but much smaller enternal flash but the speed difference would be minimal and we would be confinded to smaller builds. I think it has to do with a memory limitation in android from the dalvik vm it uses. I'm not 100% sure on what im talking about but this is the impression ive had for android for a while. Please enlighten me if I have missed something..

posting in epic thread

stickus said:
Well looks like I'm not in the closed beta, but I'm looking forward to this with great excitement. With the loss of Zen, it's good to have you back and active on this stuff again. This wouldn't happen to be Android running natively on our little wonder-units would it?
Click to expand...
Click to collapse
It's been stated before and I'll state it again, the speed of the nand (internal memory) on the vogue is very slow. Making android boot from the nand would be a step backwards... What I'm hoping I've got it a step forwards

mssmison said:
It's been stated before and I'll state it again, the speed of the nand (internal memory) on the vogue is very slow. Making android boot from the nand would be a step backwards... What I'm hoping I've got it a step forwards
Click to expand...
Click to collapse
Interesting.
I really don't understand why the internal NAND is so slow. Windows Mobile runs just fine from NAND, so why would running Android from it be any different?
Alternatively, it seems that a flashable Android would be much more convenient, and permanent.
I'm very curious to know what you're working on, mssmison.

Shidell said:
Interesting.
I really don't understand why the internal NAND is so slow. Windows Mobile runs just fine from NAND, so why would running Android from it be any different?
Alternatively, it seems that a flashable Android would be much more convenient, and permanent.
I'm very curious to know what you're working on, mssmison.
Click to expand...
Click to collapse
Duel booting would a better option in my opinion..wm is just a better mini PC OS(Windows) and Android is a better phone/internet OS . This makes our devices even more versitle then phones just running android. I dont get how just having android would makes things better..since we just manually boot android instead of it booting once the phones is turned on...how about a linux bootloader that launches before wm does..and a graphical UI to choose from the two OS's

ajclai08 said:
Duel booting would a better option in my opinion..wm is just a better mini PC OS(Windows) and Android is a better phone/internet OS . This makes our devices even more versitle then phones just running android. I dont get how just having android would makes things better..since we just manually boot android instead of it booting once the phones is turned on...how about a linux bootloader that launches before wm does..and a graphical UI to choose from the two OS's
Click to expand...
Click to collapse
My understanding is that there isn't enough room to dual-boot both WinMo and Android from the NAND on the Vogue.
You could possibly put the bootloader in NAND and run WinMo and Android from storage, but that sorta defeats the purpose.

mssmison said:
It's been stated before and I'll state it again, the speed of the nand (internal memory) on the vogue is very slow. Making android boot from the nand would be a step backwards... What I'm hoping I've got it a step forwards
Click to expand...
Click to collapse
Sounds delicious.

UHHHHHH
Well this sounds cool, Nice to see that you are back......CANT WAIT......
DROID FOR LIFE

Freezell said:
Well this sounds cool, Nice to see that you are back......CANT WAIT......
DROID FOR LIFE
Click to expand...
Click to collapse
I never left.. I was just working in the background

what's the harm in saying what's being worked on?

bug666 said:
what's the harm in saying what's being worked on?
Click to expand...
Click to collapse
Suspense is just too much fun....?

If all goes well I should have something tomorrow night for everyone.

hintttttttttttt lol

mssmison said:
If all goes well I should have something tomorrow night for everyone.
Click to expand...
Click to collapse
Is it gonna require serious work to do, like flashing a rom? Or still just files on an SDCard, just in a different way?

TheKartus said:
Is it gonna require serious work to do, like flashing a rom? Or still just files on an SDCard, just in a different way?
Click to expand...
Click to collapse
..............

lol, i've been working on stuff in the background too. haha.
but anyways, i was like wtf, this is a total bs thread, then i saw your name everywhere. haha. so i guess it's not.
good to see a vogue developer still around!!
I'm working on getting another one so I can mess with the vogue again. it's a fun phone.

Data2Ext Hack Blows Benchmarks Out of the Water

http://www.androidpolice.com/2010/12/11/data2ext-hack-blows-benchmarks-out-of-the-water/
Pretty big news out of the XDA-Forums today – forum member and resident genius Ownhere has come up with a ‘data2ext’ hack that allows users to enhance the way Android handles OS-specific data and memory. Put simply, this hack allows users to change some partition settings in order to greatly increase performance.
Originally created for the HTC Desire, the hack delivers some outstanding performance improvements and is a must have if you own the device. For more technical information, you can click here. A word of warning, though: this hack is not for the feint of heart as it is fairly difficult.
Interesting..

Pretty nice...3000 points in Quadrant is huge. Maybe we can get something similar to our devices as well...Santa Claus is approaching

not today's but they are great...if the hack doesn't destabilize the device or harm safety...
http://forum.xda-developers.com/showthread.php?t=859419

Wow, I hope someone will implement this for Legend!

qzem said:
Wow, I hope someone will implement this for Legend!
Click to expand...
Click to collapse
Same here...

I read the post howto for desire and it looked sooooooooooo complicated...

This will be fairly easy to implement... but things could go very bad using this mod. Like for instance if you make a sudden power-off... filesystem may stay in such state that it cannot be mounted on the next boot and for novice users this could mean that wipe should be made to resolve this situation.
Sent from my HTC Legend

BlaY0 said:
This will be fairly easy to implement... but things could go very bad using this mod. Like for instance if you make a sudden power-off... filesystem may stay in such state that it cannot be mounted on the next boot and for novice users this could mean that wipe should be made to resolve this situation.
Sent from my HTC Legend
Click to expand...
Click to collapse
This problem should only be there if you really disable journaling. From the original post:
As you see, the best speed is: mount real ext4 device with loop option, disable journaling. The best balance of performance and safe is mount real ext4 device with loop option, enable journaling! We don't need a loopfile but just change mount option.
Click to expand...
Click to collapse
As long as journaling is enabled this should be quite safe. At least thats what journaling is for

If someone will implement this, it would require microSD card class >= 4, to use this hack. Am I right?

ROM development, based on Eclair/Froyo anyone?

Hey
I've recently got my NST and, after TouchNootering it, I reverted it back to stock and manually rooted & installed stuff on it. I managed to install latest busybox too (1.19.1), even better than what TouchNooter installs.
Anyways, I've been wondering if anybody here is up to the challenge of making a ROM for this device. Modifying the actual ROM is nice... but it's buggy and it feels sloppy at times, not to mention it semi-works. Some features do, some don't.
I think, that if we make it possible to run a basic Eclair ROM, we can move to Froyo and maybe then, with enough experience and all, get GB or ICS installed on it. I think it's -very- possible... it just needs to be put some work on
Anyone?

Two issues: Drivers and memory. Unless drivers are available for the version of Android you want to build, you're going to have a tough time. Unless B&N releases a newer version of Android for the NST, this is probably unlikely. I suspect we're stuck on 2.1 eclair.
The NST only has 256M of memory, so a lot of what works on other devices is going to have to trimmed down.
This isn't to say that it can't be done, but by the time you're done, it may not be so much better than what we've got. Anything is possible, of course, but I'm not aware of anything along the lines of CyanogenMod in the works for the NST. I'd be happy to be wrong.
In the meantime, there's no reason improved software can't be written to run on what we've got. At least rooting makes that possible.

bobstro said:
Two issues: Drivers and memory. Unless drivers are available for the version of Android you want to build, you're going to have a tough time. Unless B&N releases a newer version of Android for the NST, this is probably unlikely. I suspect we're stuck on 2.1 eclair.
The NST only has 256M of memory, so a lot of what works on other devices is going to have to trimmed down.
This isn't to say that it can't be done, but by the time you're done, it may not be so much better than what we've got. Anything is possible, of course, but I'm not aware of anything along the lines of CyanogenMod in the works for the NST. I'd be happy to be wrong.
In the meantime, there's no reason improved software can't be written to run on what we've got. At least rooting makes that possible.
Click to expand...
Click to collapse
Hey
Well, yes, there's the issue with drivers. Thing is, and I might be wrong at this, that a driver can be kept in newer versions and still be used. For example, in HTC Magic, the video driver hasn't been updated in *ages*, and the little device can even run ICS now. Froyo, Donut & Gingerbread both use almost the same driver versions and it hasn't had any issues so far. I'm using my own experience as base on this though.
About the memory, again experience, HTC Magic has like 512 Mb ROM and 256 Mb RAM. The NST has 256 MB RAM and 2GB ROM. I find it very possible.
Thing is, I'm not very satisfied with "what we've got". See, I bought it planning to use it as a tablet instead, since... I rarely read, lol. So far so good, I can VNC/TeamView to computers at work and my computer at home, take notes and even browse the web (well, kiiiinda...), but it's buggy as hell. I mean, the rooters we have are pretty good at what they do, but the OS itself, the way B&N built it, it's broken.
See, LatinIME doesn't work correctly or is almost impossible to use with Dolphin (or any other browser) because they also broke WebCore =/. Not to mention the colors are a bit off since it's all B&W and some texts are in the same color as the background (thanks to their Framework.res theme) so...
Taking that into account, I wanted to give a go at a ROM instead, since there isn't any ROM for this device yet, and considering we have CWM working, I find it very possible to compile a ROM and use it, or hell, at least have a pure Android OS booting.
I've made some research here:
http://elinux.org/Android_on_OMAP
http://www.omappedia.org/wiki/Android_Getting_Started#Video_Tutorials
https://docs.google.com/document/d/19f7Z1rxJHa5grNlNFSkh7hQ0LmDOuPdKMQUg8HFiyzs/edit?hl=en_US
http://wiki.cyanogenmod.com/wiki/Barnes_&_Noble_Nook_Color:_Compile_CyanogenMod_(Linux)
And I think it's very possible to build a ROM, using the first two links + the tutorial at google docs. Also, it seems that some procedures, tools or code made for the Nook Color are also able to be used for the NST, since they share almost the same exact hardware.
However, I'm confused on how to start. This is my first time building an Android ROM after some few failed attempts at an HTC Magic ROM, though the instructions seem to be waaaay easier than HTC's. Right now I'm downloading Ubuntu Server 11.10 x64 so I can set up a simple OpenBox environment and start pulling code... but it's confusing
I'm up for the challenge, and I'm trying to work on it, but I'm no genius and I feel that if there's more than one person working on this, we can take a ROM out which would be better than the stock ROM and would have better and cooler stuff, like USB Host Mode already included or the refresh rate fixed/faster. Hell, I even restored it to factory defaults and then rooted it manually and installed BusyBox 1.19.1 in it, something which isn't mentioned in any tutorial that I've found yet.

darkguy2008 said:
Hey
Well, yes, there's the issue with drivers. Thing is, and I might be wrong at this, that a driver can be kept in newer versions and still be used. For example, in HTC Magic, the video driver hasn't been updated in *ages*, and the little device can even run ICS now. Froyo, Donut & Gingerbread both use almost the same driver versions and it hasn't had any issues so far. I'm using my own experience as base on this though.
Click to expand...
Click to collapse
The issue with drivers isn't so much it being old, it's getting a driver for the E-Ink screen. It's like video cards; you can put any driver you want on any computer, but unless it's the right one, you'll be stuck at 640x480 (or in the case of Android, no display).
darkguy2008 said:
About the memory, again experience, HTC Magic has like 512 Mb ROM and 256 Mb RAM. The NST has 256 MB RAM and 2GB ROM. I find it very possible.
Click to expand...
Click to collapse
It's not ROM, it's flash storage or whatever the correct term. ROM (read-only-memory) cannot be written to, and the flash storage is just storage space.
darkguy2008 said:
See, LatinIME doesn't work correctly or is almost impossible to use with Dolphin (or any other browser) because they also broke WebCore =/. Not to mention the colors are a bit off since it's all B&W and some texts are in the same color as the background (thanks to their Framework.res theme) so...
Click to expand...
Click to collapse
WebKit could probably be fixed eventually, and fixing the framework-res.apk shouldn't be too difficult, just unpack the thing with apktool and grab notepad++ or something.
darkguy2008 said:
Taking that into account, I wanted to give a go at a ROM instead, since there isn't any ROM for this device yet, and considering we have CWM working, I find it very possible to compile a ROM and use it, or hell, at least have a pure Android OS booting.
Click to expand...
Click to collapse
If we had CWM working, would this thread exist? Yes, it's working on the Nook Color, but getting it to work on the NST would require removing so many things and so much more, and even when it does happen it'd probably be a hollow shell of what it normally is.
darkguy2008 said:
I'm up for the challenge, and I'm trying to work on it, but I'm no genius and I feel that if there's more than one person working on this, we can take a ROM out which would be better than the stock ROM and would have better and cooler stuff, like USB Host Mode already included or the refresh rate fixed/faster. Hell, I even restored it to factory defaults and then rooted it manually and installed BusyBox 1.19.1 in it, something which isn't mentioned in any tutorial that I've found yet.
Click to expand...
Click to collapse
I didn't mean to put you down by all this or flame you, so hey, good luck!

Googie2149 said:
The issue with drivers isn't so much it being old, it's getting a driver for the E-Ink screen. It's like video cards; you can put any driver you want on any computer, but unless it's the right one, you'll be stuck at 640x480 (or in the case of Android, no display).
Click to expand...
Click to collapse
Hmm, you're right. I have the idea of using Eclair's drivers included in the B&N update files (1.1.2), I dunno how to use them but if the .so file exists, there must be a way to invoke their methods, no? It's just a theory, I kinda suck at this thing of kernel drivers 'n stuff.
Googie2149 said:
It's not ROM, it's flash storage or whatever the correct term. ROM (read-only-memory) cannot be written to, and the flash storage is just storage space.
Click to expand...
Click to collapse
Oh okay, then I can't seem to find any official specs of how much RAM does the NST have =/. Pretty weird.
Googie2149 said:
WebKit could probably be fixed eventually, and fixing the framework-res.apk shouldn't be too difficult, just unpack the thing with apktool and grab notepad++ or something.
Click to expand...
Click to collapse
Yeah, I have an idea of trying to fix that APK, but I wanted something more... Android-ish xD.
Googie2149 said:
f we had CWM working, would this thread exist? Yes, it's working on the Nook Color, but getting it to work on the NST would require removing so many things and so much more, and even when it does happen it'd probably be a hollow shell of what it normally is.
Click to expand...
Click to collapse
Actually, we -have- CWM working in the NST, just look here -> http://forum.xda-developers.com/showthread.php?t=1360994 . If a recovery was made possible in NST, which means some ROM (or whatever) compiling to display and use the hardware buttons, I'm very sure it is possible to build an Android ROM the same way o.o...
Googie2149 said:
I didn't mean to put you down by all this or flame you, so hey, good luck!
Click to expand...
Click to collapse
Hehe, it's okay, didn't take it as that, so, thanks
---
On another news, I followed this tutorial: http://www.omappedia.org/wiki/Android_Getting_Started up to the "repo sync" stage. It says it should take an hour and all, but it doesn't. It takes like 5 seconds, no output, nada. I don't know what could be wrong
Any help?

darkguy2008 said:
I can't seem to find any official specs of how much RAM does the NST have =/.
Click to expand...
Click to collapse
> adb shell
$ busybox free -m
Learn to love the command line.

darkguy2008 said:
Actually, we -have- CWM working in the NST, just look here -> http://forum.xda-developers.com/showthread.php?t=1360994 . If a recovery was made possible in NST, which means some ROM (or whatever) compiling to display and use the hardware buttons, I'm very sure it is possible to build an Android ROM the same way o.o...
Click to expand...
Click to collapse
Derp, I thought you were talking about Cyanogenmod for some reason.

notriddle said:
> adb shell
$ busybox free -m
Learn to love the command line.
Click to expand...
Click to collapse
Hey, I love the command line I -have- to ... Anyways, didn't thought of that first, so thanks
According to this:
Code:
total used free shared buffers
Mem: 227 212 14 0 8
-/+ buffers: 204 23
Swap: 0 0 0
The device only has 256 Mb RAM? I find it enough up to ICS. My previous HTC Magic could run ICS quite happily even without hardware acceleration, Froyo ran as fast as the stock 1.5 ROM and Gingerbread ran pretty okay. I didn't have the chance to work on optimizing it because my Magic got stolen, but I bet it could've been made to work as fast as the stock ROM if correctly optimized. Taking that into account, I'm sure this device can withstand a greater android version .
Googie2149 said:
Derp, I thought you were talking about Cyanogenmod for some reason.
Click to expand...
Click to collapse
Lol, nah XD. It it would be cool if it worked but nah, those guys prefer the most powerful devices :/ sucks though.

Okay, according to this wiki: http://wiki.samat.org/Nook ... NST's source code is here (for 1.1):
http://images.barnesandnoble.com/PResources/download/Nook/source-code/nook2_1-1.tgz
Anybody have an idea on how to compile it though? it doesn't seem complete to me.

Look here : http://forum.xda-developers.com/showthread.php?t=1290524

mdall said:
Look here : http://forum.xda-developers.com/showthread.php?t=1290524
Click to expand...
Click to collapse
That doesn't make any sense, that's for compiling a Kernel... this source code is for a whole ROM (it seems)... it has the kernel, u-boot, x-loader and some android source.
---
EDIT:
Actually... it makes sense now (after reading the whole thread, of course)... I'll see what I can do. Thanks for the link

I think radical changes of the Android version is too much to expect.
There's not a lot of ram on the Nook.
However, I just read that one of the big differences between 2.1 and 2.2
is that big changes were made to the Dalvik VM which sped it up 2X to 5X.
I think that that would be a worthy goal.

Renate NST said:
There's not a lot of ram on the Nook.
Click to expand...
Click to collapse
We won't know if nobody tries. Besides, GB has been ported to phones with less. (HTC Magic, as he already mentioned)
However, I just read that one of the big differences between 2.1 and 2.2
is that big changes were made to the Dalvik VM which sped it up 2X to 5X.
I think that that would be a worthy goal.
Click to expand...
Click to collapse
That would be awesome for stock users, but what about those apps that break under the hackish stock ROM? (ColorNote Sync, for example) Or things like NoRefresh that could take advantage of the underlying system's knowledge.

I think working around CM sources, like someone already has posted about trying, is a good idea.
CM9 might be a bit much, but CM7 is well in the device's range.
After all, it runs a CPU like my Motorola Defy, which runs CM9 without hassle (now with HWUI). It has 512MB ram though.
Look here: http://forum.xda-developers.com/showthread.php?t=1684782

imachine said:
I think working around CM sources, like someone already has posted about trying, is a good idea.
CM9 might be a bit much, but CM7 is well in the device's range.
After all, it runs a CPU like my Motorola Defy, which runs CM9 without hassle (now with HWUI). It has 512MB ram though.
Look here: http://forum.xda-developers.com/showthread.php?t=1684782
Click to expand...
Click to collapse
This thread is over a month old, and the thread specifically about CM7 is about 3 days old. But either way, I think that the NST can handle CM. The screen refresh may make it seem slow, but it actually is a little powerful (but seeing as it was my first Android device, and my only other one is a Nook Color, it might actually be as terrible as others say).

F2FS

https://en.m.wikipedia.org/wiki/F2FS
I know most people don't believe in the filesystem. However I am not one of those. I've used F2FS on previous devices and it seemed to make a difference to me. I believe it to be a faster and more efficient filesystem. Most importantly I believe flash storage will last much longer due to the difference in the way the blocks are written.
I don't consider myself a genius so... Im sure someone else knows better than me.
Just wondering if anyone was interested in porting it over our way. IRRC the hard part is building twrp to work with it.

I haven't seen any talk about it on the Pixel XL subforums, no.
Would definitely like to see it happen though.

I think TWRP has to be modded to support it
Sent from my Pixel XL using Tapatalk

Correct me if I'm wrong but I believe it would have to be supported in the kernel and TWRP at the same time due to both being in the same partition.
Sent from my Pixel XL using Tapatalk

Supported in rom kernel and recovery. I've Used it on the nexus 6 and my galaxy nexus

I used it on the Nexus 5 and 5X and loved it. Would be nice if it comes to our phone.

Why would anyone give this thread one star?
Sheesh, I gave ya five stars to try and balance it out.

CZ Eddie said:
I haven't seen any talk about it on the Pixel XL subforums, no.
Would definitely like to see it happen though.
Click to expand...
Click to collapse
You can't mate. Cause it doesn't support hardware based FBE.
---------- Post added at 08:29 AM ---------- Previous post was at 08:28 AM ----------
Oh, and btw. If any of you do end up getting f2fs, adding "nobarrier" to the joint options speeds it up crazily. The increase from that is much more than just using f2fs.
Source: http://taras.glek.net/post/Moto-Z-has-10x-less-lag-than-pixel/

LazerL0rd said:
You can't mate. Cause it doesn't support hardware based FBE.
---------- Post added at 08:29 AM ---------- Previous post was at 08:28 AM ----------
Oh, and btw. If any of you do end up getting f2fs, adding "nobarrier" to the joint options speeds it up crazily. The increase from that is much more than just using f2fs.
Source: http://taras.glek.net/post/Moto-Z-has-10x-less-lag-than-pixel/
Click to expand...
Click to collapse
Pulled this from that link you posted.
"f2fs nets Moto-Z a 2x speed-up and 2x increase in NAND lifespan. Expect Moto-Z to age much better than Pixel"

DR3W5K1 said:
Pulled this from that link you posted.
"f2fs nets Moto-Z a 2x speed-up and 2x increase in NAND lifespan. Expect Moto-Z to age much better than Pixel"
Click to expand...
Click to collapse
The mount options make a massive difference too. Check it up, mate!

CZ Eddie said:
I haven't seen any talk about it on the Pixel XL subforums, no.
Would definitely like to see it happen though.
Click to expand...
Click to collapse
It's currently impossible. F2FS doesn't support hardware file-based encryption yet.

LazerL0rd said:
It's currently impossible. F2FS doesn't support hardware file-based encryption yet.
Click to expand...
Click to collapse
It does now.

Maybe someone can get something going when the Oreo hype cools down.

What none of you read was Google's response to that guy. First of all the mount options can cause your storage to become corrupted in the event of a power failure. Also they tested f2fs internally and in real world usage it didn't make a difference in the performance of the device.
Sent from my Nexus 6P using Tapatalk

91ludesit said:
What none of you read was Google's response to that guy. First of all the mount options can cause your storage to become corrupted in the event of a power failure. Also they tested f2fs internally and in real world usage it didn't make a difference in the performance of the device.
Sent from my Nexus 6P using Tapatalk
Click to expand...
Click to collapse
It has been stated that most don't believe in the filesystem in the op. This equates no into almost no devs trying to implement it into ROMs/kernels+recoveries. It can be done and file structures stay intact. I've used it daily without any issues on my nexus 6(freewilly). Look at those or nexus 7 forums if you need proof. Everyone knows Google will never implement the fs.

DR3W5K1 said:
It has been stated that most don't believe in the filesystem in the op. This equates no into almost no devs trying to implement it into ROMs/kernels+recoveries. It can be done and file structures stay intact. I've used it daily without any issues on my nexus 6(freewilly). Look at those or nexus 7 forums if you need proof. Everyone knows Google will never implement the fs.
Click to expand...
Click to collapse
Kernel authors have added support for f2fs, NTFS and probably other file systems for ages. Then you need a TWRP build that can format to that fs.
I wouldn't take Google statement as cold hard fact. If they did everything "right" then there wouldn't be a mod community. They're is plenty of objective data showing f2fs outperforming ext4 in crucial areas like database operations.
Having said that, f2fs is not heavily utilized, a few Moto phones use it and it is pretty new fs. Samsung developed it and they don't use it. Ext4 has been around for.. 30 years? It's a nobraIner decision on their part to take the tried-and-true method rather than risk producing a million devices using a different file system that isn't nearly as developed or seasoned as ext4 is.

F2FS was definitely faster in its early days, but it had issues. As those issues were addressed, F2FS itself got slower. It no longer has a speed advantage. I'm sorry to tell you, but at this point F2FS is snake oil.

fizbanrapper said:
F2FS was definitely faster in its early days, but it had issues. As those issues were addressed, F2FS itself got slower. It no longer has a speed advantage. I'm sorry to tell you, but at this point F2FS is snake oil.
Click to expand...
Click to collapse
Just look at some motto x benchmarks you'll find your "snake oil" inside

DR3W5K1 said:
Just look at some motto x benchmarks you'll find your "snake oil" inside
Click to expand...
Click to collapse
I can't be bothered to find something I have no interest in, just to prove someone else's point for them. Lol
Having said that, I don't see any reason my F2FS shouldn't had been added to a recovery build yet if there's interest. If there are more than a handful of people interested, I can create a twrp build with F2FS support. It will take some time since I haven't synced omni repos and made my own recovery image in over six months.

DR3W5K1 said:
Just look at some motto x benchmarks you'll find your "snake oil" inside
Click to expand...
Click to collapse
Benchmarks don't mean anything when it comes to usability.
Sent from my Pixel XL using Tapatalk

External SDcard performance (US996)

I'm in the process of building a new phone configuration using a V20 (US996) running LineageOS. (14.1 at present, current nightly build)
I have a high-performance Samsung SDcard in it (128GB Evo Select) which is capable of about ~60MB/s write and 100MB/s or more read speed.
In my LG G4 (also running LOS but a late November 2017 build), using a 64GB version of the same card, I get around 45MB/s write speed based on a couple of benchmarking tools I have.
But the V20 only seems to achieve 15-18MB/s write speed.
Is this some kind of terrible hardware flaw with the V20, or ???

Exabyter said:
I'm in the process of building a new phone configuration using a V20 (US996) running LineageOS. (14.1 at present, current nightly build)
I have a high-performance Samsung SDcard in it (128GB Evo Select) which is capable of about ~60MB/s write and 100MB/s or more read speed.
In my LG G4 (also running LOS but a late November 2017 build), using a 64GB version of the same card, I get around 45MB/s write speed based on a couple of benchmarking tools I have.
But the V20 only seems to achieve 15-18MB/s write speed.
Is this some kind of terrible hardware flaw with the V20, or ???
Click to expand...
Click to collapse
You should probably ask this in the lineage thread
Sent from my LG-H910 using XDA Labs

cnjax said:
You should probably ask this in the lineage thread
Click to expand...
Click to collapse
Your comment makes little sense.
The OS in both examples I mentioned is mostly the same, the main difference is the phone hardware.
I am simply trying to ascertain whether this sort of performance is common for that device when using a high-speed card.

Exabyter said:
Your comment makes little sense.
Click to expand...
Click to collapse
No, it makes sense.
Lineage for V20 is not the same as for G4, or most other devices for that matter.
This might be some problem with the LOS lg msm8996 kernel, which of course LOS for the G4 does not use.

All I'm trying to ascertain is what kind of speed people are seeing with their V20's in general.
If' it's significantly better than what I'm seeing, I'll check the OS-specific forums. Thanks.

Exabyter said:
All I'm trying to ascertain is what kind of speed people are seeing with their V20's in general.
If' it's significantly better than what I'm seeing, I'll check the OS-specific forums. Thanks.
Click to expand...
Click to collapse
Get way faster than that but I'm on stock ROM so that doesn't help sorry. I'll try to find my other thread I had in here that has my results
I've never used lineage on v20 but that would be prime suspect considering all the roadblocks getting it to even run right that I've read about lol
---------- Post added at 04:31 AM ---------- Previous post was at 03:36 AM ----------
Exabyter said:
All I'm trying to ascertain is what kind of speed people are seeing with their V20's in general.
If' it's significantly better than what I'm seeing, I'll check the OS-specific forums. Thanks.
Click to expand...
Click to collapse
https://forum.xda-developers.com/v20/accessories/huge-micro-sd-cards-t3498278
That's the thread if you are interested there area free other benchmarks from other people.
Trying to attach the pictures of the card and results but it keeps saying network error on xda labs. I'll try later but I think they were on page 8

Using A1 SD Bench on Super V20 with MK2000 and a 200GB Sandisk A1 microSD I get
Read: 78.8mb/s
Write: 27.20mb/s

KUSOsan said:
Get way faster than that but I'm on stock ROM so that doesn't help sorry.
Click to expand...
Click to collapse
Actually that helps quite a bit, since it corroborates my initial conclusion that this is not a hardware issue, it's a software issue.
KUSOsan said:
I've never used lineage on v20 but that would be prime suspect considering all the roadblocks getting it to even run right that I've read about lol
Click to expand...
Click to collapse
Oh? Do tell. I haven't had the V20 for long yet but I did already get a response elsewhere that there were some unique things about it besides the "2nd screen" thingy and DACs.
KUSOsan said:
https://forum.xda-developers.com/v20/accessories/huge-micro-sd-cards-t3498278
That's the thread if you are interested there area free other benchmarks from other people.
Click to expand...
Click to collapse
Great resource, would probably have taken me a long time to find that on my own. Thanks much, I'll look at it a bit later.

XblackdemonX said:
Using A1 SD Bench on Super V20 with MK2000 and a 200GB Sandisk A1 microSD I get
Read: 78.8mb/s
Write: 27.20mb/s
Click to expand...
Click to collapse
Thanks much.
The write speed there is still a bit disappointing though, given that that card should be able to do, according to some reports, at least 2x if not 3x higher than that.

Exabyter said:
Thanks much.
The write speed there is still a bit disappointing though, given that that card should be able to do, according to some reports, at least 2x if not 3x higher than that.
Click to expand...
Click to collapse
Not really, in THIS test, you can see the SDSQUAR does 33.4mb/s write and 92.8mb/s read. I'm in the range.